cvs commit: modperl-2.0/src/modules/perl mod_perl.c
dougm 02/04/05 17:23:17 Modified:src/modules/perl mod_perl.c Log: use AP_FTYPE_RESOURCE rather than AP_FTYPE_CONTENT_SET Revision ChangesPath 1.111 +2 -2 modperl-2.0/src/modules/perl/mod_perl.c Index: mod_perl.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v retrieving revision 1.110 retrieving revision 1.111 diff -u -r1.110 -r1.111 --- mod_perl.c6 Apr 2002 01:19:15 - 1.110 +++ mod_perl.c6 Apr 2002 01:23:17 - 1.111 -504,11 +504,11 ap_register_output_filter(MP_FILTER_REQUEST_OUTPUT_NAME, modperl_output_filter_handler, - AP_FTYPE_CONTENT_SET); + AP_FTYPE_RESOURCE); ap_register_input_filter(MP_FILTER_REQUEST_INPUT_NAME, modperl_input_filter_handler, - AP_FTYPE_CONTENT_SET); + AP_FTYPE_RESOURCE); ap_register_output_filter(MP_FILTER_CONNECTION_OUTPUT_NAME, modperl_output_filter_handler,
cvs commit: modperl-2.0/t/response/TestDirective perlrequire.pm
dougm 02/04/05 17:42:53
Modified:lib .cvsignore
lib/ModPerl Code.pm
t/conf modperl_extra.pl
t/response/TestDirective perlrequire.pm
Added: lib Apache2.pm
Log:
no longer generate Apache2.pm
add an Apache2.pm that scans INC for Apache2/ directories rather than
hardcode paths as the old generated one did.
use Apache2 (); in the tests so t/TEST can run when built with
MP_INST_APACHE2=1
Revision ChangesPath
1.2 +1 -1 modperl-2.0/lib/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/modperl-2.0/lib/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- .cvsignore30 Apr 2000 03:34:00 - 1.1
+++ .cvsignore6 Apr 2002 01:42:52 - 1.2
-1 +1
-Apache2.pm
+
1.1 modperl-2.0/lib/Apache2.pm
Index: Apache2.pm
===
package Apache2;
BEGIN {
my dirs = ();
for my $path (INC) {
my $dir = $path/Apache2;
next unless -d $dir;
push dirs, $dir;
}
if (dirs) {
unshift INC, dirs;
}
}
1;
1.76 +0 -29 modperl-2.0/lib/ModPerl/Code.pm
Index: Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -r1.75 -r1.76
--- Code.pm 21 Feb 2002 01:45:34 - 1.75
+++ Code.pm 6 Apr 2002 01:42:53 - 1.76
-681,35 +681,6
#create bootstrap method for static xs modules
my $static_xs = [keys %{ $build-{XS} }];
ExtUtils::Embed::xsinit($xsinit, 1, $static_xs);
-
-warn generating..., $self-generate_apache2_pm, \n;
-}
-
-sub generate_apache2_pm {
-my $self = shift;
-
-my $lib = $self-perl_config('installsitelib');
-my $arch = $self-perl_config('installsitearch');
-my $file = $self-default_file('apache2_pm');
-
-open my $fh, '', $file or die open $file: $!;
-
-my $package = 'package Apache2';
-
-print $fh noedit_warning_hash();
-
-print $fh EOF;
-$package;
-
-use lib qw($lib/Apache2
- $arch/Apache2);
-
-1;
-
-EOF
-close $fh;
-
-$file;
}
my $constant_prefixes = join '|', qw{APR?};
1.13 +2 -0 modperl-2.0/t/conf/modperl_extra.pl
Index: modperl_extra.pl
===
RCS file: /home/cvs/modperl-2.0/t/conf/modperl_extra.pl,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- modperl_extra.pl 8 Jan 2002 22:46:08 - 1.12
+++ modperl_extra.pl 6 Apr 2002 01:42:53 - 1.13
-1,3 +1,5
+use Apache2 ();
+
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache::RequestRec ();
1.6 +1 -0 modperl-2.0/t/response/TestDirective/perlrequire.pm
Index: perlrequire.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestDirective/perlrequire.pm,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- perlrequire.pm18 Jan 2002 06:57:32 - 1.5
+++ perlrequire.pm6 Apr 2002 01:42:53 - 1.6
-9,6 +9,7
use strict;
use warnings FATAL = 'all';
+use Apache2 ();
use Apache::Test ();
use Apache::Const -compile = 'OK';
use File::Spec::Functions qw(catfile);
cvs commit: modperl-2.0 .cvsignore Makefile.PL
dougm 02/04/05 20:01:56
Modified:..cvsignore Makefile.PL
Log:
generate MANIFEST during make dist
Revision ChangesPath
1.6 +1 -0 modperl-2.0/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/modperl-2.0/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- .cvsignore6 Mar 2002 05:24:57 - 1.5
+++ .cvsignore6 Apr 2002 04:01:56 - 1.6
-5,3 +5,4
scraps
diff.txt
smoke-report-*.txt
+MANIFEST
1.61 +17 -2 modperl-2.0/Makefile.PL
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- Makefile.PL 6 Apr 2002 02:12:14 - 1.60
+++ Makefile.PL 6 Apr 2002 04:01:56 - 1.61
-71,6 +71,9
clean = {
FILES = { clean_files() },
},
+dist = {
+DIST_DEFAULT = 'mydist',
+},
);
post_configure();
-209,7 +212,8
return [@{ $build-clean_files },
xs/*.exp, xs/*.def,
- map { $path/$_} { $code-clean_files }];
+qw(MANIFEST),
+map { $path/$_} { $code-clean_files }];
}
sub set_modperl_version {
-358,7 +362,9
}
sub MY::postamble {
-'';
+return EOF;
+mydist : manifest tardist
+EOF
}
sub MY::tool_autosplit {
-389,4 +395,13
\t.'PERL=$(PERL)\\',
\t.'DEFINE=$(DEFINE)',
;
+}
+
+sub MY::dist_basics {
+my $self = shift;
+my $str = $self-MM::dist_basics;
+
+$str =~ s/-MExtUtils(::Manifest=mkmanifest)/-Ilib -MModPerl$1/;
+
+$str;
}
Re: Access right on files from CGI script
I would say you should set up suexec to let the user that Apache runs as execute those specific commands as a privaleged user. But use suexec with EXTREME care. Issac bo wrote: Hello gurus, I am notivice on Apache configuration. I wrote a CGI program, which will display some system status on the client PC's browser window. This CGI program will execute a couple of system command under /sbin with reading some system status from /proc. I have no problem to access or execute any file or binary under /www/cgi-bin but I have an access problem to other system directories like /sbin or /proc. I followed the apache configuration document and I modified directory and created .htaccess file under /sbin but it did not help. How do I allow those files accessible from the CGI script? Please help me out. Thanks in advance, Bo
Thanks and GoodBye
Hi, Thanks for all your help, but I am NOT able to install mod_perl. It's probably something that is not installed on my particular server - I'll never know. After spending several weeks (almost solid) tweaking the configuration and trying various scenarios to no avail I finally realized that there is no way for me to figure out what is wrong. It's not so bad, I am still able to do CGI programming w/ no problems. Enjoy, and thanks again for all your support. John Kolvereid __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
RE: Thanks and GoodBye
Hi John, I haven't been following your case in details but my oppinion is that if you have a clean install of any common Unix platform (or at least one mentioned in the mod_perl doc.) it should be no problem to install a default mod_perl enabled Apache. From what I can see you use Redhat 6.2 which is _very_ common I guess. Personally I don't use anything but FreeBSD, and mod_perl has never caused my big problems. Most Unix distributions come out of the box well capable of installing mod_perl right away... to my knowledge. That being said, I have had times when it didn't make all the output files needed for merging mod_perl into my httpd. But that has only been the case when I also wanted mod_php and mod_ssl in the same httpd. So my suggestion is, that you either clean your current box and re-install from scratch (if it's not a production site), or try a clean install on a new test box if you have that available. You should definately not give up. It's not hard at all. Best of luck // Nicolai -Original Message- From: John Kolvereid [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 1:14 PM To: [EMAIL PROTECTED] Subject: Thanks and GoodBye Hi, Thanks for all your help, but I am NOT able to install mod_perl. It's probably something that is not installed on my particular server - I'll never know. After spending several weeks (almost solid) tweaking the configuration and trying various scenarios to no avail I finally realized that there is no way for me to figure out what is wrong. It's not so bad, I am still able to do CGI programming w/ no problems. Enjoy, and thanks again for all your support. John Kolvereid __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: Thanks and GoodBye
John Kolvereid wrote: Hi, Thanks for all your help, but I am NOT able to install mod_perl. don't give up, john. it's a hard road, especially for those just starting out, but it is worth it :) I haven't read all of your thread in detail, but I would suggest that if you are really having that much trouble that you take a few baby steps first and try a binary distribution of mod_perl. for instance, most linux distributions have pre-compiled binary packages for both Apache and mod_perl (as a DSO) that work rather well out of the box. Solaris also has a binary mod_perl package. and if you just want to start playing with mod_perl's features, I've seen absolutely nothing easier than Randy's Win32 distribution of Perl/Apache/mod_perl (which can be found at ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-0.7.exe) - I was simply amazed at how quickly I was able to install Randy's package and run stuff immediately. for instructions on installing the various binary packages, you can see chapter 1 of the cookbook (http://www.modperlcookbook.org/chapters/ch01.pdf), as well as the valuable information in the eagle book and guide that I'm sure you've looked over already. in particular, there's a section in the guide for installing redhat rpms which, though a bit dated now, is still pretty accurate. HTH --Geoff
RE: Thanks and GoodBye
Thanks for all your help, but I am NOT able to install mod_perl. John, I don't know if anyone has mentioned this before, but have you tried the Apache Toolbox (http://www.apachetoolbox.com/)? Before you give up completely it might be worth trying. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ http://wypug.digital-word.com/
AuthCookie login ?
Is there a hook in AuthCookie to allow me to run some code only right after successful login? The model doesn't seem to allow for this. The way it seems to work is you attempt to log in, if it doesn't find a valid cookie, it displays the login form again. You submit that and it sets the cookie without authenticating the login, then issues a redirect to the page the user was originally trying to go to. When the browser comes back via the redirect, the cookie is already present, and only then does AuthCookie attempt to authenticate the cookie. Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. It would seem wasteful to check for the presence of the Apache::Session object every trip to the server just to determine if this is the first request or not. Is there a hook or a flag with that same functionality? Thanks, Fran
Re: AuthCookie login ?
Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. can't you do this in authen_cred()? IIRC authen_cred is only called when no cookie is found, which means you have a first time visit (or an unsuccessful attempt). you have control here to execute code only when a valid user is found, since it's up to you to determine if the user is valid. authen_ses_key() then checks whether the cookie itself (containing the session key) is valid. at least this is how I remember it working - it's been a while since I've worked with AuthCookie. --Geoff
Re: Thanks and GoodBye
John Kolvereid wrote: Thanks for all your help, but I am NOT able to install mod_perl. It's probably something that is not installed on my particular server - I'll never know. I suspect you were just trying to do too much at once on your first try by throwing PHP and SSL in the mix. I suggest you look at SpeedyCGI (http://daemoninc.com/speedycgi/), which offers similar speedups for CGI scripts but does not require you to recompile Apache. It doesn't have the same feature set as mod_perl, but all you wanted to do was speed up your existing CGI scripts anyway. - Perrin
the coming of Apache 2.0
The modssl-userslist is all abuzz about the coming of Apache 2.0. I don't hear a lot on this list on mod_perl support for Apache 2.0. Is anyone planning to adopt this configuration in the near future? Chuck
www.modperl.com .. ?
According to the subscription notice ... www.modperl.com is a resource site but I've tried many times ... is this site still valid?
mod_perl Cook Book
Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. Thanks in advance -r
Re: mod_perl Cook Book
The cookbook is fabulous. In my opinion it's much clearer than the Eagle book. Of course it has the benefit of having been written when mod_perl had a few more years of maturity under it's belt. =) The Cookbook is wonderful and I would also like to publicly thank Geoffrey Young, one of the authors, for the generous amounts of help he has provided me via email. Buy it, you'll like it! -Fran Rasoul Hajikhani wrote: Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. Thanks in advance -r
Re: mod_perl Cook Book
Rasoul Hajikhani [EMAIL PROTECTED] wrote: Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. Thanks in advance I enjoyed it -- I have it on my desk ready to crack open at a moment's notice. But then, I'm a bit biased since I'm mentioned in it :) It's been invaluable in writing some mod_perl handlers lately (Uttu.pm - 0.02 next week, hopefully, much improved). You'll want to either get the next print run or take a look at the errata on www.modperlcookbook.org if you run into problems. There don't seem to be a lot of large, glaring problems, just small things that can be easily overlooked. A few sample chapters are also available at that site. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: the coming of Apache 2.0
On Fri, 5 Apr 2002, Chuck Goehring wrote: The modssl-users list is all abuzz about the coming of Apache 2.0. I don't hear a lot on this list on mod_perl support for Apache 2.0. Is anyone planning to adopt this configuration in the near future? http://perl.apache.org/~dougm/modperl_2.0.html sterling
Re: mod_perl Cook Book
Rasoul Hajikhani wrote: Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Yes. Go get it. - Perrin
Re: www.modperl.com .. ?
At 11:24 AM 4/5/02 -0600, [EMAIL PROTECTED] wrote: According to the subscription notice ... www.modperl.com is a resource site but I've tried many times ... is this site still valid? Works fine from here... Elizabeth Mattijsen
Re: www.modperl.com .. ?
At 11:24 AM -0600 4/5/2002, [EMAIL PROTECTED] wrote: According to the subscription notice ... www.modperl.com is a resource site but I've tried many times ... is this site still valid? It redirects to http://modperl.com:9000/ which, if your connection lives behind a firewall, may be blocked. -Charles [EMAIL PROTECTED] -- Charles Albrecht Euonymic Solutions [EMAIL PROTECTED] P.O. Box 300623 C303.619.7596 F978.334.3061 Denver, Colorado 80203-0623 http://www.euonymic.net/~charlesa/cv/
Pipelinning Output APP Framework
I know alot of you must do this. I want build a simple APP framework to chain the output of all my content handlers, which would live in many different PM's for easy code management. for example: APP::Header APP::Footer APP::Content APP::Chemical_entry APP::... APP::Controller - would push_handlers based on uri and/or app logic - The result would be the entire html output in ( via print array ) WHY ( so that my content can: ) - pass named paired parameters to following handlers - modify previous content ( eg update html header code with a msg from main content handler ) Is any one doing something similar that could be used in a production enviroment ? - via memvory - via tie ( the list messages seem to bash this approach ) - some other method My goal is to develop an open source chemical tracking system. The requirements are -web based -FAST -DB session tracking -FAST, FAST, FAST ( mod perl seems to be the best ) -perl -FAST -DBI -FAST -Postgres -SSL
Re: Open3
In local.modperl you write: I have asked this question before, and received answers that have helped me in quest. However, my problem persists. So I would like to direct this question to those who have used gpg, and open3. I am having trouble writing to stdin when an apache thread calls open3. However, the same code written as a test script runs fine. I am using the --passphrase-fd 0 option which would instruct gpg to expect the passphrase from stdin rather than keyboard. As I mentioned above, the problem arises when an apache thread tries to execute my code. I know that under perl 5.6 it is necessary to untie STDIN,... (thanks Don Hayward), but I am using perl 5.005_03 built for irix ( Apache/1.3.12 Ben-SSL/1.39 (Unix) mod_perl/1.22). What is happening that I am missing? I'm vaguely remembering reading an article that said this is very non-trivial, and that there is a module to help with the hard part. Have you had a look at Crypt::GPG? http://search.cpan.org/doc/AGUL/Crypt-GPG-1.28/GPG.pm HTH, Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm|
sun4-solaris polluted installation
Hi everyone, I have to (re)install mod_perl enabled Apache on prod server, which is polluted with the several previous unsuccessful attempts to do the similar job. It is not my server, but I may sudo su, when sure that the main prod (which is running on pure Apache using perl CGI scripts) will remain working... Basically, I need to clean up the mess and to install a brand new mod_perl enabled dedicated Apache to use some of my handlers for the performance demonstration. Actually, I need somebody very experienced with the sun4-solaris environment to assist me carefully on this slippery road... # perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos tensor.vnet.net 5.6 generic_105181-06 sun4u sparc sunw,ultra-1 ' config_args='-Dcc=gcc -de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFS ET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.6' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at May 10 2001 06:56:03 INC: /usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl Libraries in initial conditions: # ls -l /usr/local/lib/perl5/5.6.1/sun4-solaris/ total 1166 drwxr-xr-x 3 root other 1024 Mar 12 19:50 Apache -r--r--r-- 1 root other 35434 May 1 2001 Apache.pm drwxr-xr-x 2 bin bin 512 Mar 12 19:36 B -r--r--r-- 1 bin bin16467 May 10 2001 B.pm drwxr-xr-x 2 root other512 Mar 12 19:50 Bundle -r--r--r-- 1 bin bin 603 May 10 2001 ByteLoader.pm drwxr-xr-x 2 bin bin 1024 Mar 12 19:36 CORE -r--r--r-- 1 bin bin 188975 May 10 2001 Config.pm -r--r--r-- 1 bin bin57760 May 10 2001 DB_File.pm drwxr-xr-x 2 bin bin 512 Mar 12 19:36 Data drwxr-xr-x 2 bin bin 512 Mar 12 19:36 Devel -r--r--r-- 1 bin bin27317 May 10 2001 DynaLoader.pm -r--r--r-- 1 bin bin 6953 May 10 2001 Errno.pm -r--r--r-- 1 bin bin 5216 May 10 2001 Fcntl.pm drwxr-xr-x 2 bin bin 512 Mar 12 19:36 File -r--r--r-- 1 bin bin 1930 May 10 2001 GDBM_File.pm drwxr-xr-x 3 bin bin 512 Mar 29 12:17 IO -r--r--r-- 1 root other742 Jul 23 1998 IO.pm drwxr-xr-x 2 bin bin 512 Mar 12 19:36 IPC -r--r--r-- 1 bin bin 2408 May 10 2001 NDBM_File.pm -r--r--r-- 1 bin bin 2651 May 10 2001 O.pm -r--r--r-- 1 bin bin 2406 May 10 2001 ODBM_File.pm -r--r--r-- 1 bin bin15195 May 10 2001 Opcode.pm -r--r--r-- 1 bin bin18796 May 10 2001 POSIX.pm -r--r--r-- 1 bin bin50095 May 10 2001 POSIX.pod -r--r--r-- 1 bin bin 2517 May 10 2001 SDBM_File.pm -r--r--r-- 1 bin bin16668 May 10 2001 Safe.pm -r--r--r-- 1 bin bin10564 May 10 2001 Socket.pm drwxr-xr-x 2 bin bin 512 Mar 12 19:36 Sys -r--r--r-- 1 bin bin 3619 May 10 2001 XSLoader.pm -r--r--r-- 1 bin bin 1432 May 10 2001 attrs.pm drwxr-xr-x 25 bin bin 512 Mar 12 19:50 auto -r--r--r-- 1 root other 3277 Mar 3 2000 cgi_to_mod_perl.pod -r--r--r-- 1 root other 1096 Jul 11 2001 mod_perl.pm -r--r--r-- 1 root other 27538 Nov 28 2000 mod_perl.pod -r--r--r-- 1 root other 2706 Feb 29 2000 mod_perl_cvs.pod -r--r--r-- 1 root other512 Mar 12 16:44 mod_perl_hooks.pm -r--r--r-- 1 root other
Re: Problem with DBM concurrent access
I would also suggest using BerkeleyDB.pm, but with the DB_INIT_MPOOL|DB_INIT_CDB flags. In this mode, only one writer is allowed at a time, and Berkeley automatically handles all the locking and flushing. Just don't forget to use db_close() to close the file before untie'ing it. Dan Wilga [EMAIL PROTECTED] Web Technology Specialist http://www.mtholyoke.edu Mount Holyoke CollegeTel: 413-538-3027 South Hadley, MA 01075 Who left the cake out in the rain?
Re: sun4-solaris polluted installation
Hi there, On Fri, 5 Apr 2002, Slava Bizyayev wrote: I have to (re)install mod_perl enabled Apache on prod server, which is polluted with the several previous unsuccessful attempts [snip] Actually, I need somebody very experienced with the sun4-solaris environment to assist me carefully on this slippery road... It's not that difficult. You can build another Apache with mod_perl and run it on the same machine without having any effect at all on the existing server, which can continue to run as normal. All you have to do is to configure the new server to listen to a port other than port 80 (to which presumably your production server is currently listening) and you can play with your new server until you get it to do what it needs to do. The details are all in the Guide: http://perl.apache.org/guide and you might also want to have a look at the Eagle Book: Writing Apache Modules with Perl and C, ISBN 1-56592-567-X and/or the Cookbook http://www.modperlcookbook.org if you haven't already. 73, Ged. (PS: GY: OK?)
Re: Pipelinning Output APP Framework
On Fri, 2002-04-05 at 12:41, [EMAIL PROTECTED] wrote: I know alot of you must do this. I want build a simple APP framework to chain the output of all my content handlers, which would live in many different PM's for easy code management. for example: APP::Header APP::Footer APP::Content APP::Chemical_entry APP::... APP::Controller - would push_handlers based on uri and/or app logic - The result would be the entire html output in ( via print array ) WHY ( so that my content can: ) - pass named paired parameters to following handlers - modify previous content ( eg update html header code with a msg from main content handler ) Is any one doing something similar that could be used in a production enviroment ? - via memvory - via tie ( the list messages seem to bash this approach ) - some other method You might look at OpenFrame, they're doing neat stuff with pipelines. It's on CPAN and at http://openframe.fotango.com/ Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Pipelinning Output APP Framework
[EMAIL PROTECTED] wrote: I know alot of you must do this. I want build a simple APP framework to chain the output of all my content handlers, which would live in many different PM's for easy code management. for example: APP::Header APP::Footer APP::Content APP::Chemical_entry APP::... APP::Controller - would push_handlers based on uri and/or app logic - The result would be the entire html output in ( via print array ) WHY ( so that my content can: ) - pass named paired parameters to following handlers - modify previous content ( eg update html header code with a msg from main content handler ) This is not the best way to think about the problem, especially if you want it to be FAST, FAST, FAST. Having one piece of code manipulate the HTML output from another piece is messy, slow, and will probably break every time your designers change the HTML. Instead, build a pipeline for working on the data to be displayed, which you can easilly pass through method arguments or $r-pnotes(), and then run a template (which may include many smaller templates) at the end to generate HTML. There are several templating tools you can use for this, and I've summarized the best ones at http://perl.apache.org/features/tmpl-cmp.html. - Perrin
Re: Problem with DBM concurrent access
Hello, DWI would also suggest using BerkeleyDB.pm, but with the DWDB_INIT_MPOOL|DB_INIT_CDB flags. In this mode, only one writer is DWallowed at a time, and Berkeley automatically handles all the locking DWand flushing. Just don't forget to use db_close() to close the file DWbefore untie'ing it. One caveat on this, BerkeleyDB maintains its locks and other environment information in a local memory segment so this won't work if multiple machines share the same BerkeleyDB file (e.g., you are using the BerkeleyDB file over NFS). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: sun4-solaris polluted installation
Nice try. Unfortunately, helpless... Don't you see two instances of mod_perl in common perl libraries? That's just flowers... When I try to make install, for example # make install Writing /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Apache/Filter/.packli st Appending installation info to /usr/local/lib/perl5/5.6.1/sun4-solaris/perllocal.pod Funny? Not for me... Best regards, Slava - Original Message - From: Ged Haywood [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, April 05, 2002 3:51 PM Subject: Re: sun4-solaris polluted installation Hi there, On Fri, 5 Apr 2002, Slava Bizyayev wrote: I have to (re)install mod_perl enabled Apache on prod server, which is polluted with the several previous unsuccessful attempts [snip] Actually, I need somebody very experienced with the sun4-solaris environment to assist me carefully on this slippery road... It's not that difficult. You can build another Apache with mod_perl and run it on the same machine without having any effect at all on the existing server, which can continue to run as normal. All you have to do is to configure the new server to listen to a port other than port 80 (to which presumably your production server is currently listening) and you can play with your new server until you get it to do what it needs to do. The details are all in the Guide: http://perl.apache.org/guide and you might also want to have a look at the Eagle Book: Writing Apache Modules with Perl and C, ISBN 1-56592-567-X and/or the Cookbook http://www.modperlcookbook.org if you haven't already. 73, Ged. (PS: GY: OK?)
Re: Pipelinning Output APP Framework
Hi there, On Fri, 5 Apr 2002 [EMAIL PROTECTED] wrote: [snip,snip] My goal is to develop an open source chemical tracking system. The requirements are -web based -FAST These two requirements are mutually exclusive. If you can be a little more specific about your requirements I can probably be more helpful. 73, Ged.
Re: mod_perl Cook Book
On Fri, 5 Apr 2002, Rasoul Hajikhani wrote: Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. I have two copies, as the one at work keeps getting borrowed. I would say it's different to the Eagle book - it takes a different tack (which is kinda the point). I find both books useful - the Eagle book for explaining the Apache request cycle very clearly, and the Cookbook for explaining some of the nuances of mod_perl very clearly. Basically the Cookbook is much more about solving specific problems than the Eagle book, and as such is much more useful long term and short term, and I also found the explanations a bit clearer in the Cookbook. So I'd get both, but the Cookbook first if you're new to mod_perl, and then the Eagle book if you're still confused about some issues. I promised Geoff I would do a full review, and I'm doing an OS upgrade this weekend, so perhaps I'll get a chance to go over the bits of the book I've missed so far and post the review somewhere. -- !-- Matt -- :-Get a smart net/:-
proxy front to modperl back with 1.3.24
i had trouble using a proxy front end to both a mod_perl and mod_php back end servers. this works fine for me at 1.3.23, so I reverted back to it. i copied the httpd.conf files from the 1.3.24 to my downgraded 1.3.23 and everything worked correctly on the first try. i was getting garbage characters before the first html or doctype tag, and a 0 character at the end. also, there was a delay before the connection would close. i tried turning keep alives off and on in the back end server, but i did not note a change in behavior i also tried some different buffer directives, including the new ProxyIOBufferSize. these garbage characters and delays were not present serving static content from the front end server, or when directly requesting content directly from either of the back end servers. i know they've made some mods to the proxy module, including support for HTTP/1.1, but i did not have time to research the exact cause of the problem. just a word of warning before someone spends hours in frustration, or perhaps someone can give me a tip if they've solved this problem. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: proxy front to modperl back with 1.3.24
On Fri, Apr 05, 2002 at 02:33:35PM -0800, ___cliff rayman___ wrote: i had trouble using a proxy front end to both a mod_perl and mod_php back end servers. this works fine for me at 1.3.23, so I reverted back to it. i copied the httpd.conf files from the 1.3.24 to my downgraded 1.3.23 and everything worked correctly on the first try. i was getting garbage characters before the first html or doctype tag, and a 0 character at the end. also, there was a delay before the connection would close. i tried turning keep alives off and on in the back end server, but i did not note a change in behavior i also tried some different buffer directives, including the new ProxyIOBufferSize. That was the size of the document when you get it in a chunked response. And there were some problems in 1.3.24 where mod_proxy returned the data it had collected in the chunked format even if the client requesting the data didn't explicitly ask for it. these garbage characters and delays were not present serving static content from the front end server, or when directly requesting content directly from either of the back end servers. i know they've made some mods to the proxy module, including support for HTTP/1.1, but i did not have time to research the exact cause of the problem. just a word of warning before someone spends hours in frustration, or perhaps someone can give me a tip if they've solved this problem. There are some few messages concerning the problem a while ago either on this list or the dev@httpd list. http://msgs.securepoint.com/cgi-bin/get/apache0204/1/3.html etc. Can't really remember if they have fixed it in CVS already. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
Re: proxy front to modperl back with 1.3.24
Thomas Eibner wrote: There are some few messages concerning the problem a while ago either on this list or the dev@httpd list. http://msgs.securepoint.com/cgi-bin/get/apache0204/1/3.html etc. thanks - it must have been a bad googling day yesterday since i did not come up with this info. Can't really remember if they have fixed it in CVS already. i'll wait till 1.3.25 which will probably be coming out sooner than expected. ;-) -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: proxy front to modperl back with 1.3.24
On Fri, Apr 05, 2002 at 03:23:38PM -0800, ___cliff rayman___ wrote: Thomas Eibner wrote: There are some few messages concerning the problem a while ago either on this list or the dev@httpd list. http://msgs.securepoint.com/cgi-bin/get/apache0204/1/3.html etc. thanks - it must have been a bad googling day yesterday since i did not come up with this info. Somehow google actually just indexed that message it seems, Apr 05 was the time stamp. But there was some discussion about it on dev@httpd when 1.3.24 was released. Can't really remember if they have fixed it in CVS already. i'll wait till 1.3.25 which will probably be coming out sooner than expected. ;-) Let's see - with the dev people pushing for GA on 2.0. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
ANNOUNCE: Bricolage 1.3.1
The Bricolage development team is proud to announce the release of Bricolage version 1.3.1. This is a development release with new features as well as numerous bug fixes. Summary of major changes (see the Changes file in the distribution for details): * SOAP interface fully implemented * New FTP distribution move method * New preferences to change the way URIs are formatted Here's a brief description of Bricolage: Bricolage is a full-featured, open-source, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. More information on Bricolage can be found on its home page. http://bricolage.thepirtgroup.com/ And it can be downloaded from SourceForge. http://sourceforge.net/project/showfiles.php?group_id=34789 --The Bricolage Team
Re: Open3
On Wed, 03 Apr 2002 13:54:09 -0800, Rasoul Hajikhani wrote: Elizabeth Mattijsen wrote: At 01:44 PM 4/3/02 -0800, Rasoul Hajikhani wrote: Hello folks, I am writing a web based interface to gpg and am using IPC::Open3 Try IPC::Run -- Cheers Ron Savage, [EMAIL PROTECTED] on 06/04/2002 http://savage.net.au/index.html
RE: proxy front to modperl back with 1.3.24
-Original Message- From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 3:34 PM To: [EMAIL PROTECTED] Subject: proxy front to modperl back with 1.3.24 i had trouble using a proxy front end to both a mod_perl and mod_php back end servers. this works fine for me at 1.3.23, so I reverted back to it. i copied the httpd.conf files from the 1.3.24 to my downgraded 1.3.23 and everything worked correctly on the first try. i was getting garbage characters before the first html or doctype tag, and a 0 character at the end. also, there was a delay before the connection would close. i tried turning keep alives off and on in the back end server, but i did not note a change in behavior i also tried some different buffer directives, including the new ProxyIOBufferSize. these garbage characters and delays were not present serving static content from the front end server, or when directly requesting content directly from either of the back end servers. I have the exact same type setup with my machine. 1.3.24 front-end serving up a modperl 1.3.24 backend. As already noted, chunked responses (with their garbage characters delineating the seperation of chunks) are a HTTP/1.1 response. If a HTTP/1.0 client asks for something, it needs to get a 1.0 response. The problem is that when the front-end Apache proxy passes the request onto the mod_perl server, it now always seems to make a 1.1 request. So when the mod_perl Apache sees this, it answers in 1.1 (chunked), and the front-end Apache server passes this 1.1 response onto 1.0 client. I figured this out really quickly when people started writing in and saying what are all the garbage characters? I found a solution that works. In the mod_perl Apache httpd.conf file, I added this section: IfModule mod_setenvif.c BrowserMatch downgrade-1.0 force-response-1.0 BrowserMatch . downgrade-1.0 force-response-1.0 BrowserMatch / downgrade-1.0 force-response-1.0 BrowserMatch _ downgrade-1.0 force-response-1.0 /IfModule It basically catches any browser that has a space, period, slash, or underscore. This covers every browser or crawler I had seen. What this does is forces the mod_perl Apache to answer in HTTP/1.0. So: When a 1.0 client makes a request, the front-end Apache passes this request onto the mod_perl Apache as a 1.1 request (stupidly), but the mod_perl Apache will only answer in 1.0. So the front-end Apache just passes this 1.0 request on. When a 1.1 client makes a request, the front-end Apache passes this request onto the mod_perl Apache as a 1.1 request (not stupidly), the mod_perl Apache will answer in 1.0, but then the front-end Apache will re-format the request into a 1.1 request to answer the 1.1 client. What amazingly baffles me is that the Apache team does not have the most minor test suite that they run to check on things before they make releases. They have a history of these kinds of problems. In my mind, they are famous for re-occuring bugs. Everytime a bug is found and fixed, a test routine needs to be built for it that checks for this bug in all future releases. I love Apache, and the people behind are amazing, but I am always paranoid of new releases because of all these recurring (or stupidly easy to find) bugs. Mark
solution to readdir/opendir mod_perl problem: rebuild!
We upgraded our systems to RedHat 7.2 with glibc2.2.4
and all of a sudden, our mod_perl scripts which call
readdir() would either fail with an exception, or
readdir() in list context would return the correct # of
items but each item as an empty string.
We scanned the modperl list and found about 50 posts in
about 8 threads on this topic (!) but no answers.
There were various workaround suggestions, such as
using glob(), but these were not useful to us since we
rely on a number of third-party perl modules which call
readdir() and it was not practical to modify them.
We discovered that this problem is caused by a build
mismatch between perl and mod_perl that is a result of
a nasty binary incompatibility between glibc2.2.4 and
glibc2.1.3. So much for DSO versioning!
To get rid of the problem, you _must_ rebuild perl from
scratch on a system with glibc2.2.4 (in our case we had
perl 5.6.1), then you _must_ rebuild mod_perl from
scratch on the same system (we had mod_perl 1.26) and
then build and run httpd on the same system.
(ok, technically it doesn't have to be the same system,
but you must have the same glibc version installed
during each build and also when you run httpd).
Or if you're not the building type, you'll need to
locate some pre-done build that was done entirely
on a system with glibc2.2.4.
The analysis of the problem goes something like this:
- the code which is hurt by the glibc incompatibility
is the code that actually calls the C readdir()
function. it gets built into
/opt/perl/lib/5.6.1/i686-linux/CORE/libperl.a by the
perl build.
- that code is then statically linked into mod_perl by
the mod_perl build (regardless of whether mod_perl
itself is statically or dynamically linked to httpd).
- when you build libperl.a on RedHat 6 with glibc2.1.3,
struct dirent is 272 bytes long and dirent.d_name is at
offset 15.
- when you build libperl.a on RedHat 7 with glibc2.2.4,
struct dirent is 276 bytes long and dirent.d_name is at
offset 19.
- a compile time / runtime discrepancy here could
definitely cause the symptom we're seeing (right number
of files, but empty filenames) because the struct is
like this:
struct dirent {
longd_ino;
__kernel_off_t d_off;
unsigned short d_reclen;
chard_name[256];
};
If glibc2.2 placed the name at the correct place, but
libperl.a was reading it out 4 bytes early, then
libperl.a would probably see a byte of 0 as the first
byte of the name, hence looking like an empty C string.
We say this because d_off is probably either 0 all the
time (since the man page says Use of other fields
[including d_off] will harm the portability of your
programs,) or it's probably 0 because it's the third
byte of d_off and you'd have to have a directory that
was 256*256 bytes or more in order to get a nonzero
value for d_off on a little endian machine. So really
this bug discriminates against people with a lot of
files or big-endian machines :) We could test this
theory by creating large directories but we're happy
that rebuilding it works :)
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Re: solution to readdir/opendir mod_perl problem: rebuild!
Louis Semprini wrote: We upgraded our systems to RedHat 7.2 with glibc2.2.4 and all of a sudden, our mod_perl scripts which call readdir() would either fail with an exception, or readdir() in list context would return the correct # of items but each item as an empty string. We scanned the modperl list and found about 50 posts in about 8 threads on this topic (!) but no answers. There were various workaround suggestions, such as using glob(), but these were not useful to us since we rely on a number of third-party perl modules which call readdir() and it was not practical to modify them. We discovered that this problem is caused by a build mismatch between perl and mod_perl that is a result of a nasty binary incompatibility between glibc2.2.4 and glibc2.1.3. So much for DSO versioning! To get rid of the problem, you _must_ rebuild perl from scratch on a system with glibc2.2.4 (in our case we had perl 5.6.1), then you _must_ rebuild mod_perl from scratch on the same system (we had mod_perl 1.26) and then build and run httpd on the same system. (ok, technically it doesn't have to be the same system, but you must have the same glibc version installed during each build and also when you run httpd). Thanks a lot Louis, This solution will appear in the next release of the guide in the troubleshooting chapter. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache 2.0 gold -- now when mod_perl 2.0?
It looks like Apache 2.0(.35) is 'gold', so when can we expect a 'gold' version of mod_perl 2.0 so we can actually make apache 2 fun? ;p Jon Coulter [EMAIL PROTECTED]
RE: mod_perl Cook Book
I bought it two weeks ago, as a mod_perl newbie, and recommend it. I really like the cookbook style: 'You want to XXX' = snippet / recipe. If you already read Perl, it is fast and compact. I have had questions along the way [specific to the cookbook], but posting a question on this list gets an almost immediate response. Summation: Worth the money - buy it. Regards Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 05 April 2002 21:13 To: [EMAIL PROTECTED] Subject: mod_perl Cook Book Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. Thanks in advance -r
Software Integration Testing
I was wondering if anyone has any experiences in Software Integration Testing using home made or known methodologies that are being used. I came across one called Cyclomatic Complexity (for example) The context being The software system has three subsystems; Two subsystems in the kernel and one subsystem (a multi-threading C++ application) in user land. Components are identified as kernel modules. (think installable kernel modules). I am looking for the following - Books on software integration testing - URLs on software integration testing - Methodologies that you have worked with or read up on that might work - Home made solutions that you designed Thanks -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
