Trouble writing to a file from mod_perl
I'm trying to write for a file from a mod_perl script. I can write successfully to a file located in /tmp, but I cannot write to the dir containing the script, nor to the apache logs dir. How can this be accomplished? Is there a setting in httpd.conf that I need to specify? Is it a file permissions problem? I don't want to make the script dir world read/writable. Would the Apache::Log interface allow me to write to my own file? My code looks something like the following: open(LOG, /usr/local/apache/htdocs/aws/perl/rod.log) || print script.pl: Can't write to log file.; print LOG hello\n; close LOG I'm running mod_perl 1.27 and Apache 1.3.27 on Mandrake Linux. Any help would be greatly appreciated. Rod Brick
Re: Trouble writing to a file from mod_perl
Rod Brick wrote: I'm trying to write for a file from a mod_perl script. I can write successfully to a file located in /tmp, but I cannot write to the dir containing the script, nor to the apache logs dir. How can this be accomplished? Is there a setting in httpd.conf that I need to specify? Is it a file permissions problem? I don't want to make the script dir world read/writable. Would the Apache::Log interface allow me to write to my own file? My code looks something like the following: open(LOG, /usr/local/apache/htdocs/aws/perl/rod.log) || print script.pl: Can't write to log file.; print LOG hello\n; close LOG change it to open(LOG, /usr/local/apache/htdocs/aws/perl/rod.log) || print script.pl: Can't write to log file : $! ; print LOG hello\n; close LOG And at least it'll tell yuo why it can't write to the file :) Carl
Re: Trouble writing to a file from mod_perl
Hello Rod Brick, Thursday, July 31, 2003, 3:01:57 PM, you wrote: RB I'm trying to write for a file from a mod_perl script. I can write RB successfully to a file located in /tmp, but I cannot write to RB the dir containing the script, nor to the apache logs dir. How can RB this be accomplished? Is there a setting in httpd.conf that I RB need to specify? Is it a file permissions problem? I don't want to RB make the script dir world read/writable. Would the Apache::Log RB interface allow me to write to my own file? My code looks something RB like the following: open(LOG, /usr/local/apache/htdocs/aws/perl/rod.log) || print RB script.pl: Can't write to log file.; RB print LOG hello\n; RB close LOG RB I'm running mod_perl 1.27 and Apache 1.3.27 on Mandrake Linux. Any RB help would be greatly appreciated. RB Rod Brick I'm pretty sure -- this is a permission problem. You could check $! to see the source of the problem and print it to STDERR instead of STDOUT which under mod_perl is tied to client socket (of couse if you want to see message in the error log). open(...) || print STDERR Some problem to open: $!\n; Depends of you apache/mod_perl setup it's quite possible that your apache processes run under user which has no privileges to write into /usr/local/apache/htdocs/aws/perl/rod.log. -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 Those who learn from history are doomed to have it repeated to them anyway.
Privilege separation revisited
This is something I asked before, like one or two years ago. I just want to see if a solution has come up since then. The problem is that with the normal (linux-distro) installation of apache and mod_perl, all processes for all active scripting (cgi, perl, PHP..) run as the same user. Thus, if I run a mod_perl app which keeps a data repository in a file, then that file need to grant write permissions to the web user. If there are untrusted users with access to PHP on the system, then this becomes a problem, since they could easily overwrite that file with a simple script. One may ask why untrusted users should have access to PHP, but this is often the case with student servers in academics, specifically in computer science. The question is, what is the state-of-the-art approach for protecting data written to a file by mod_perl from being overwritten by an untrusted user? Is it possible to run all mod_perl things as a separate user (without having to keep two parallel apache installations)? // Joel
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stephen Clouse wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 30, 2003 at 11:15:32PM +0200, Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. The only problem so far is the ithreads mod_perl takes three glacial eons to start issue. You brought that up on modperl-dev a few days ago but I haven't had a chance to rebuild everything with ithreads until now. Did you ever hear anything from Arthur? That was a different though related issue. since mod_perl's test suite is huge (loads about 100 test modules + about 50 normal modules) it takes a long time to copy the mutable data when creating a new perl clone. That should be fixed when perl implements COW (copy-on-write), so it'll work similar to the OS-level sharing. However this won't happen in 5.8.1 :( __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-print() problem with UTF-8 data in Perl 5.8
Steve Hay wrote:
Randy Kobes wrote:
On Tue, 29 Jul 2003, Steve Hay wrote:
Is anybody going to take a serious look at the problem that I
previously
reported with Apache-print()'s handling of UTF-8 data in Perl 5.8?
The patch that I sent
(http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2)
seems to fix it for me on Windows as long as I've got perl #20203
incorporated. Does it work on other platforms?
The #ifdef version-checks need a little work: on Windows (and other
platforms [-- which ones?] that rely on Perl's makedef.pl to get
symbols
exported from the Perl library) you need perl-5.8.1; on other platforms
the test for perl-5.8.0 should be fine. The brokenness of
Apache-print() under perl-5.8.0 on Windows et al would also need
documenting somewhere since it can't be fixed properly.
mod_perl 2 makes two special cases for handling systems that use
export files - Win32 and aix ($^O eq 'aix'). So these might
be the only two one has to worry about in this regard.
These were the only two that Nicholas Clark mentioned when I asked
about the missing PerlIO_isutf8() on the perl-xs list, so that may
well be true. I will double-check with p5p to see if there are any more.
Apparently there are a few more -- several listed in Perl's makedef.pl,
plus VMS which evidently has a completely different build process.
The attached patch (against mod_perl 1.28) sorts out the version-check
stuff, which was the only remaining issue that I had. This leaves
Apache-print() broken on Windows et al under Perl 5.8.0, and fixes it
under Perl 5.8.0 on other platforms and under Perl 5.8.1+ on all platforms.
Steve
--- Apache.xs.orig 2003-06-06 12:31:10.0 +0100
+++ Apache.xs 2003-07-31 09:45:37.0 +0100
@@ -51,6 +51,16 @@
#include mod_perl.h
#include mod_perl_xs.h
+/* Figure out if we've got PerlIO_isutf8(). This is needed to handle UTF-8
+ * data correctly in Perl 5.8.0+, but was not exported by Perl in 5.8.0 itself
+ * on those OS's where symbols to export have to be explicitly listed. */
+#if !( PERL_REVISION 5 || \
+ (PERL_REVISION == 5 PERL_VERSION 8) || \
+ (PERL_REVISION == 5 PERL_VERSION == 8 PERL_SUBVERSION == 0 \
+ (defined(WIN32) || defined(NETWARE) || defined(OS2) || \
+defined(_AIX) || defined(MACOS_TRADITIONAL) || defined(VMS))) )
+#define _HAVE_ISUTF8
+#endif
#ifdef USE_SFIO
#undef send_fd_length
@@ -1119,11 +1129,27 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+#ifdef _HAVE_ISUTF8
+ PerlIO *fp = IoOFP(GvIOp(defoutgv));
+#endif
if(items 2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+#ifdef _HAVE_ISUTF8
+ if (PerlIO_isutf8(fp)) {
+ if (!SvUTF8(sv))
+ sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+ }
+ else if (DO_UTF8(sv)) {
+ if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ckWARN_d(WARN_UTF8))
+ {
+ Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+ }
+ }
+#endif
PUSHMARK(sp);
XPUSHs(rp);
@@ -1176,6 +1202,20 @@
int sent = 0;
SV *sv = SvROK(ST(i)) (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
(SV*)SvRV(ST(i)) : ST(i);
+#ifdef _HAVE_ISUTF8
+ PerlIO *fp = IoOFP(GvIOp(defoutgv));
+ if (PerlIO_isutf8(fp)) {
+ if (!SvUTF8(sv))
+ sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+ }
+ else if (DO_UTF8(sv)) {
+ if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ckWARN_d(WARN_UTF8))
+ {
+ Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+ }
+ }
+#endif
buffer = SvPV(sv, len);
#ifdef APACHE_SSL
while(len 0) {
Re: Privilege separation revisited
Joel Palmius wrote: This is something I asked before, like one or two years ago. I just want to see if a solution has come up since then. The problem is that with the normal (linux-distro) installation of apache and mod_perl, all processes for all active scripting (cgi, perl, PHP..) run as the same user. Thus, if I run a mod_perl app which keeps a data repository in a file, then that file need to grant write permissions to the web user. If there are untrusted users with access to PHP on the system, then this becomes a problem, since they could easily overwrite that file with a simple script. One may ask why untrusted users should have access to PHP, but this is often the case with student servers in academics, specifically in computer science. The question is, what is the state-of-the-art approach for protecting data written to a file by mod_perl from being overwritten by an untrusted user? Is it possible to run all mod_perl things as a separate user (without having to keep two parallel apache installations)? That would be possible with mod_perl 2.0, when Apache releases the perchild mpm. Since at this moment nobody seems to be interesting in finishing it off, I can't tell you when it's going to be available. If you have tuits to complete it (there is a working prototype) email the httpd-dev list. Alternatively you may want to sponsor one of the developers to do the work. For more information see: http://httpd.apache.org/docs-2.0/mod/perchild.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Privilege separation revisited
Hello Joel Palmius, Thursday, July 31, 2003, 3:12:02 PM, you wrote: JP This is something I asked before, like one or two years ago. I just want JP to see if a solution has come up since then. JP The problem is that with the normal (linux-distro) installation of apache JP and mod_perl, all processes for all active scripting (cgi, perl, PHP..) JP run as the same user. Thus, if I run a mod_perl app which keeps a data JP repository in a file, then that file need to grant write permissions to JP the web user. If there are untrusted users with access to PHP on the JP system, then this becomes a problem, since they could easily overwrite JP that file with a simple script. JP One may ask why untrusted users should have access to PHP, but this is JP often the case with student servers in academics, specifically in computer JP science. JP The question is, what is the state-of-the-art approach for protecting data JP written to a file by mod_perl from being overwritten by an untrusted user? JP Is it possible to run all mod_perl things as a separate user (without JP having to keep two parallel apache installations)? Not sure what you meant about 'two parallel apache installations' but anyway. We have real working internet solution which I think safe enough. Even we do not use any content generating approaches other than mod_perl I think our solution will work with them. We have one DSO (linux) manually compiled apache whith two (actually more) config files (DSO to avoid two binaries). One for external proxy-cache apache. And one or more for internal real working-horse apaches. We start external proxy to serve static content and dispatch requests to the internal processes which serves dynamic content (we call it application servers). Proxy run under nobody and application server run under user which has enough rights to open/read/write private resources. Usually this is normal OS user and application server has ServerRoot=$HOME of this user. So with backend app server no priviledges conflict and resources is not world writable. Proxy listen internet connections and app servers has no access from internet. Actually things more complicated, but I thik I was clear in our approach. -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 You're much more likely to be knocked down by a snowball than by an equivalent number of snowflakes.
Re: Privilege separation revisited
From: Joel Palmius [EMAIL PROTECTED] Date: Thu, 31 Jul 2003 11:12:02 +0200 (CEST) The question is, what is the state-of-the-art approach for protecting data written to a file by mod_perl from being overwritten by an untrusted user? Is it possible to run all mod_perl things as a separate user (without having to keep two parallel apache installations)? You don't need, parallel installations, just parallel instances. One main server running on port 80 set up to proxy requests to the relevant user's process. Individual users have their own httpd.conf set up with a unique port under a unique user (themselves, for instance). Each instance is started by simply running: $ httpd -f /path/to/that/users/httpd.conf _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
Re: Trouble with Apache::Request
On 6 Jun 2003, K Old wrote: [...] Well, here are the errors I'm getting: When I *force* and install of Apache::Request and a script calls Apache::Request, this is in the error_log: [Fri Jun 6 17:27:31 2003] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm line 22. This is from doing a make test when trying to install Apache::Request manually: Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. This patch resolves this problem: http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w=2 it should go in in the next release. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. BAD NEWS: There seems to be a problem with ExtUtils-MakeMaker 6.12 included in perl-5.8.1-RC3. I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl as well, and found that it doesn't build. I get the following error: ... link -out:..\blib\arch\auto\libapreq\libapreq.dll ... libapreq.def : error LNK2001: unresolved external symbol boot_libapreq If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in perl-5.8.0) then it it's all OK. The question is: why is it trying to build libapreq.dll? It should only build Request.dll and Cookie.dll, which would probably explain why boot_libapreq is undefined. I'll continue looking into it myself, and can supply more info to anyone that wants it, but I thought I'd better raise the alarm quickly first. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. BAD NEWS: There seems to be a problem with ExtUtils-MakeMaker 6.12 included in perl-5.8.1-RC3. I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl as well, and found that it doesn't build. I get the following error: ... link -out:..\blib\arch\auto\libapreq\libapreq.dll ... libapreq.def : error LNK2001: unresolved external symbol boot_libapreq If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in perl-5.8.0) then it it's all OK. The question is: why is it trying to build libapreq.dll? It should only build Request.dll and Cookie.dll, which would probably explain why boot_libapreq is undefined. I'll continue looking into it myself, and can supply more info to anyone that wants it, but I thought I'd better raise the alarm quickly first. I have a similar problem on linux, Request.so dynamically links libapreq.so, which subsequently can't be found. I'm looking at it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Trouble with Apache::Request
I had this exact same issue yesterday. I noticed that is was installing the libapreq.so.1 in /usr/local/lib and /usr/local/lib wasn't in my /etc/ld.so.conf file. Just add /usr/local/lib to your /etc/ld.so.conf file and then run ldconfig .. Worked for me and I was messing with the darn thing for about 3 hours. . Glenn E. Bailey III . Sprocket Data, Inc. . http://www.sprocketdata.com : -Original Message- : From: Stas Bekman [mailto:[EMAIL PROTECTED] : Sent: Thursday, July 31, 2003 6:48 AM : To: K Old : Cc: ModPerl List : Subject: Re: Trouble with Apache::Request : : : On 6 Jun 2003, K Old wrote: : : [...] : : Well, here are the errors I'm getting: : : When I *force* and install of Apache::Request and a script calls : Apache::Request, this is in the error_log: [Fri Jun 6 : 17:27:31 2003] : [error] Can't locate object method new via package : Apache::Request : at : : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request. : pm : line 22. : : This is from doing a make test when trying to install : Apache::Request : manually: : : Syntax error on line 31 of : /root/.cpan/build/libapreq-1.1/t/httpd.conf: : Can't load : : '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/ : Request.so' for module Apache::Request: libapreq.so.1: cannot : open shared object file: No such file or directory at : /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. : at : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm : line 14 : Compilation failed in require at (eval 16) line 3. : : This patch resolves this problem: : http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w= 2 it should go in in the next release. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: compile latest CVS
Stas Bekman wrote: You can also try to use the latest src.rpm from rawhide, I'm not sure how recent it is http://fr.rpmfind.net//linux/RPM/rawhide/1.0/i386/RedHat/RPMS/mod_perl-1.99_09-6.i386.html says Jul 16, which is very recent. great, I got the source rpm of the above, after compiling and installing it on my redhat 9 system it works fine :-) I have even got the authCookieLdap module working after playing with compat and cheat a bit on use strict , more on this in my next mail to the list ; subject: Re: problem with method auth_type thanks a lot to all of you .
Re: Trouble with Apache::Request
Glenn E. Bailey III wrote: I had this exact same issue yesterday. I noticed that is was installing the libapreq.so.1 in /usr/local/lib and /usr/local/lib wasn't in my /etc/ld.so.conf file. Just add /usr/local/lib to your /etc/ld.so.conf file and then run ldconfig .. Worked for me and I was messing with the darn thing for about 3 hours. It shouldn't have installed it in first place. actually there are a few more patches on win32 that will go in soon. A new release will make those problems go away. . Glenn E. Bailey III . Sprocket Data, Inc. . http://www.sprocketdata.com : -Original Message- : From: Stas Bekman [mailto:[EMAIL PROTECTED] : Sent: Thursday, July 31, 2003 6:48 AM : To: K Old : Cc: ModPerl List : Subject: Re: Trouble with Apache::Request : : : On 6 Jun 2003, K Old wrote: : : [...] : : Well, here are the errors I'm getting: : : When I *force* and install of Apache::Request and a script calls : Apache::Request, this is in the error_log: [Fri Jun 6 : 17:27:31 2003] : [error] Can't locate object method new via package : Apache::Request : at : : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request. : pm : line 22. : : This is from doing a make test when trying to install : Apache::Request : manually: : : Syntax error on line 31 of : /root/.cpan/build/libapreq-1.1/t/httpd.conf: : Can't load : : '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/ : Request.so' for module Apache::Request: libapreq.so.1: cannot : open shared object file: No such file or directory at : /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. : at : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm : line 14 : Compilation failed in require at (eval 16) line 3. : : This patch resolves this problem: : http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w= 2 it should go in in the next release. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problem with method auth_type
OK, it works now :-)
On my redhat 9 system, I recompiled from rawhide latest source rpm, now
I run with:
$ rpm -q mod_perl httpd
mod_perl-1.99_09-6
httpd-2.0.47-1
by using apache::compat, PerlOptions +GlobalRequest and cheating on the
use strict it now works :-), i can authenticate through https to an
ldap server through authcookieldap module .
I know authcookie is about to be port to mod_perl 2 and apache 2, and I
hope it will allowed me to run a cleaner configuration .
for those of you interested, here's what I went through:
httpd.conf
PerlModule Apache2
PerlModule Apache::AuthCookieLDAP
PerlSetVar INTAuthPath /
PerlSetVar INTAuthLoginScript /perl/login.pl
PerlSetVar INTAuthSatisfy Any
PerlSetVar INTAuthExpires +2h
# These must be set
PerlSetVar INTAuthLDAP_DN dc=int-evry,dc=fr
PerlSetVar INTAuthLDAP_SecretKeyFile /etc/httpd/conf/ssl.key/ca.key
PerlSetVar INTAuthLDAP_User uid
PerlSetVar INTAuthDBI_DSN mysql:test
#PerlSetVar INTAuthLDAP_filter F=on
PerlSetVar INTAuthLDAP_host ldapserver.int-evry.fr
PerlSetVar INTAuthLDAP_EncryptionType none
PerlSetVar INTAuthLDAP_SessionLifetime 00-24-00-00
# Protected by AuthCookieLDAP.
Location /mci
PerlOptions +GlobalRequest
PerlFixupHandler Apache::DB
AuthType Apache::AuthCookieLDAP
AuthName INTAuth
PerlAuthenHandler Apache::AuthCookieLDAP-authenticate
PerlAuthzHandler Apache::AuthCookieLDAP-authorize
Limit GET POST
require valid-user
/Limit
/Location
Files LOGIN
#PerlOptions +GlobalRequest
AuthType Apache::AuthCookieLDAP
AuthName INTAuth
SetHandler perl-script
PerlHandler Apache::AuthCookieLDAP-login
/Files
cheat:
$ /etc/init.d/httpd restart
Stopping httpd:[FAILED]
Starting httpd: [Thu Jul 31 14:47:09 2003] [error] Bareword OK not allowed
while strict subs in use at
/usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookieLDAP.pm line 755.
Bareword FORBIDDEN not allowed while strict subs in use at
/usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookieLDAP.pm line 758.
Compilation failed in require at (eval 4) line 3.
so I commented out use strict; in
/usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookieLDAP.pm , :-(
Then accessing the /mci ldap protected directory in a navigator,
generated the following http error.log
[Thu Jul 31 14:49:38 2003] [error] [client 157.159.50.198] Global $r
object is
not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookie.pm
line 216.
So I added PerlOptions +GlobalRequest in httpd.conf as stated above !.
thanks to all of you .
PS: Authors of authcookie and authcookieldap, please let me know if you
port your modules to apache 2 and mod_perl 2.
Stas Bekman wrote:
jehan procaccia wrote:
hello,
I followed the thread :
http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/mod_perl_2.0_question_about_$r-%3Econnection-%3Eauth_type_P51273/#51273
While using module AuthCookieLDAP based on AuthCookie I got exactly
the same error:
Use of uninitialized value.
[Wed Jul 23 16:25:54 2003] [error] [client 127.0.0.1] Can't locate
object
method auth_type via package Apache::Connection at
/usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookie.pm line 182.!, referer:
http://localhost/ldap
I am trying to Authenticate HTTP connection to an openldap Server,
using AuthCookie and AuthCookieLDAP, both written for apache 1.3.X
and mod_perl 1.X. Here I use Apache 2.0.40 and mod_perl-1.99_07-5
(which is supposed to be mod_perl 2.0 I understood !?) on a RedHat 9
system.
Although I added PerlModule Apache::compat and PerlOptions
+GlobalRequest in httpd.conf , I still get the above mentioned error
:-(
Any help ?
Thanks.
PS: The author of AuthCookie is about to port its module to mod_perl
2.0, maybe that would solve the problem, but when, and why doesn't it
work now with Apache::compat ?
http://perl.apache.org/docs/2.0/user/porting/compat.html#C__connection_E_gt_auth_type_
Have you tried the latest cvs of mod_perl2? Apache::compat provides
the necessary code there:
package Apache::Connection;
# auth_type and user records don't exist in 2.0 conn_rec struct
# 'PerlOptions +GlobalRequest' is required
sub auth_type { shift; Apache-request-ap_auth_type(@_) }
sub user { shift; Apache-request-user(@_) }
For more info see:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Privilege separation revisited
Hello, JPThe question is, what is the state-of-the-art approach for protecting data JPwritten to a file by mod_perl from being overwritten by an untrusted user? JPIs it possible to run all mod_perl things as a separate user (without JPhaving to keep two parallel apache installations)? pYou don't need, parallel installations, just parallel instances. p pOne main server running on port 80 set up to proxy requests to the prelevant user's process. p pIndividual users have their own httpd.conf set up with a unique port punder a unique user (themselves, for instance). On an Internet exposed system you don't necessarily want to permit those httpds to run as actual users. Instead, it is probably safer to make a number of unprivileged users (www-perl, www-username, www-php, or whatever) that have no shells (or whatever other security restrictions you are interested in) and have the httpds run as them. You can put them in the same group as the related user (for example if user andrew is in group andrew, you can create a www-andrew user with no shell, but in group andrew so files can be shared). This minimizes the damage a badly written CGI can do (blow away any group writeable files in group andrew, for example, rather than blow away any of user andrew's files plus do bad stuff masquerading as user andrew). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
uwinnipeg site down (ppm installation)?
Hello, I am trying to install mod_perl 2 (1.99_10) from the http://theoryx5.uwinnipeg.ca/ppms/ site, but it seems to be down. Could anyone point me to a mirror or send me the necessary files off-list? It would be very appreciated, since I am in something of a hurry. BTW, I am looking forward to using mod_perl and asking+answering questions on this list. Thanks in advance, J-S ___Jean-Sébastien Guay [EMAIL PROTECTED]Software Developer, Hybride http://www.hybride.comPiedmont, Québec, Canada
PerlAuthenHandler problem with mod_perl in a Cobalt Raq4
Hi There, I need to use Apache::AuthDBI to authenticate users via MySQL and InterBase in a Cobalt Raq4. I'm using this method in another linux boxes but this particular Raq4 is driving me mad. Raq4 comes with an Apache with a pre compile mod_perl 1.25 withall hooks enable, including PerlAuthenHandler and PerlAuthzHandler. But no matter what I pass to PerlAuthenHandler or PerlAuthzHandler it does not work, Apache seens to be ignoring it. An exemple of my .htaccess file: AuthName "Protected Dir"AuthType BasicPerlAuthenHandler Apache::AuthDBI::authen PerlSetVar Auth_DBI_encrypted offPerlSetVar Auth_DBI_data_source dbi:mysql:xPerlSetVar Auth_DBI_username PerlSetVar Auth_DBI_password PerlSetVar Auth_DBI_pwd_table PerlSetVar Auth_DBI_uid_field PerlSetVar Auth_DBI_pwd_field require valid-user If I access this directory the authentication window pops-up (as usual), If I try to logon as a database user I get this error in my "error" log: [Thu Jul 24 03:05:10 2003] [error] access to /home/sites/home/web/test failed for xxx.xxx.xxx.xxx, reason: AuthPamExternal [/usr/lib/authenticate]: Failed (1) for user x Now, the real odd thing is that if I try to access this diretory as a regular local system user, it authenticates! The Apache shipped with Raq4 uses the mod_auth_pam_external but I don't know if this have something do with this problem, as the mod_auth works fine. The Apache or mod_perlseens to be ignoring the PerlAuthenHandler directive ... If I use: PerlAuthenHandler Apache::AuthDBI::authen It does not work if I use: PerlAuthenHandler BOGUS::BOGUS::BOGUS It, of course, does not work, but I don't get any error about it my log files! And also, I still can logon as a regular local user. Any ideas/thoughts ?!? Any help would be apprecitate ... Thank you, Antonio
Accessing environment variables prior to invoking the contenthandler.
Hi Group,
I have a need to access all the %ENV (cgi,mod_perl sent by the client)
variables prior to invoking the content handler. I am using the modperl
environment by running the cgi scripts under Perl::Registry. I wish to
use the PerlTransHandler to check if the request for page A has
orginated from page B. If it did then redirect to page C.
I have used the following code in the in my handler and I still do not
get the values. This was recommended by the Writing Apache Modules by
Doug M and Lincoln S.
sub handler {
my $r=shift;
my $env=$r-subprocess_env;
%ENV=%$senv;
my $referer=$ENV{'HTTP_REFERER'};
x
}
Thank you for the help in advance.
Mark
Re: Accessing environment variables prior to invoking the contenthandler.
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote: I have used the following code in the in my handler and I still do not get the values. Do you get anything at all? HTTP_REFERER is not always sent by browsers. - Perrin
Accessing environment variables prior to invoking thecontenthandler.
Only PERL_SEND_HEADER=On. No other env. variables. I did run tests by clicking on links to check to see if the HTTP_REFERER is being set. Mark.
Filter brigades with rflush() not working?
Hello
According to [1], $r-rflush() should create a new brigade with
data. It does not. It seems the docs and/or my understanding of this
is in error (probably the latter...).
This is with:
Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
And I am using the streaming filter api.
[1]
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers
Long version below:
---
I have tried to make my outputfilter clever enough so it can handle
being called several times, with tags potentially split between
several brigades.
Now I would like to test this somehow (ie, force mod_perl to call my
filter several times). I tried using $r-rflush(), but cannot get it
to work as I and the docs would expect.
I tried creating a ResponseHandler which explicitly breaks some silly
html data into brigades:
sub handler {
my $r = shift;
$r-content_type('text/html');
$r-log_error (Cutting);
$r-print (htmlhead title /head); $r-rflush();
$r-print (bo);$r-rflush();
$r-print (dy body ); $r-rflush();
$r-print (/html);
$r-log_error (Cutting: end);
return Apache::OK;
}
And then a simple 'DebugFilter' output filter which just prints each chunk:
sub handler : FilterRequestHandler {
my $f = shift;
$f-r-log_error (DebugFilter called);
$f-print (DebugFilter called\n);
while ($f-read(my $buffer, 1024)) {
$f-print(CHUNK:$buffer:CHUNK\n);
}
return Apache::OK;
}
And httpd.conf
Location /test/
PerlResponseHandler MyApache::Cutter
PerlOutputFilterHandler MyApache::DebugFilter
/Location
When I run this, I see that DebugFilter gets called 4 times (3
rflush's + 1 eos or something). But the strange thing is that only the
_last_ call contains data. That data is _everything_ nicely
concatenated and not splitted as I would guess.
Here is actual output:
$ wget --quiet -O - http://localhost/test/
DebugFilter called
DebugFilter called
DebugFilter called
DebugFilter called
CHUNK:htmlhead title /headbody body /html:CHUNK
And the error_log:
[Thu Jul 31 21:52:42 2003] [error] Cutting: start
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] Cutting: end
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
Re: Accessing environment variables prior to invoking thecontenthandler.
On Thu, 2003-07-31 at 16:15, Mark Deepak Puttnam wrote: Only PERL_SEND_HEADER=On. No other env. variables. And you haven't turned off PerlSetupEnv in your httpd.conf? - Perrin
Re: Accessing environment variables prior to invoking the contenthandler.
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
sub handler {
my $r=shift;
my $env=$r-subprocess_env;
%ENV=%$senv;
my $referer=$ENV{'HTTP_REFERER'};
x
}
Come to think of it, you should just use the Apache API for this:
my $referer = $r-header_in(Referer);
- Perrin
Accessing environment variables prior to invoking the contenthandler.
I did not have that directive in my config before. But now,I set it explicitly to PerlSetupEnv On , still no env variables other than the PERL_SEND_HEADER=On. Mark
Accessing environment variables prior to invoking thecontenthandler.
Hi Perrin, my $referer = $r-header_in(Referer); Thanks, the above statement did give me the value. Mark
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 31, 2003 at 11:41:42AM +0200, Stas Bekman wrote: Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. *** mod_perl version 1.9910 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS= /opt/apache/bin/apxs MP_COMPAT_1X = MP_DEBUG = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_MAINTAINER = 1 MP_TRACE = 1 MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /opt/apache/bin/httpd -V Server version: Apache/2.0.47 Server built: Jul 30 2003 17:58:08 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/opt/apache -D SUEXEC_BIN=/opt/apache/bin/suexec -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /opt/perl/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.20-19.8, archname=i686-linux-thread-multi uname='linux stephenc.theiqgroup.com 2.4.20-19.8 #1 tue jul 15 15:25:37 edt 2003 i686 i686 i386 gnulinux ' config_args='-des -Dprefix=/opt/perl -Dinstallprefix=/opt/perl -Dvendorprefix=/opt/perl -Dsiteprefix=/opt/perl -Dmyhostname=localhost [EMAIL PROTECTED] -Dcf_by=IQG-SPC -Dcc=gcc -Doptimize=-O3 -march=i686 -mcpu=i686 -ggdb3 -Duseshrplib -Duseperlio -Dusethreads -Duseithreads -Dusemymalloc' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 -march=i686 -mcpu=i686 -ggdb3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing' ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/opt/perl/lib/5.8.1/i686-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: RC3 Built under linux Compiled at Jul 30 2003 17:12:12 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /opt/perl/lib/5.8.1/i686-linux-thread-multi /opt/perl/lib/5.8.1 /opt/perl/lib/site_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/site_perl/5.8.1 /opt/perl/lib/site_perl /opt/perl/lib/vendor_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/vendor_perl/5.8.1 /opt/perl/lib/vendor_perl . Unfortunately a couple of the modules we're using don't want to cooperate with ithreads (XML::GDOME is a notable one). I'm working on patches for these; in the meantime, I'll at least give it a thorough run-through with prefork. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KZcHA4aoazQ9p2cRAmaXAKCIE5sROjyScppt8qu47Pm7LJw6kgCfajBU 1E4cCfuKlCnKzdwCuQVzUzw= =H4RV -END PGP SIGNATURE-
Re: Trouble with Apache::Request
Hi All,
perl-5.8.0 + mp1.99_10.
---
I am having problem trying to get /perl-status work.
It bombs out in Status.pm at the following location:
--
if (eval {require Apache::Request}) {
$newQ ||= sub { Apache::Request-new(@_) };
}
elsif (eval {require CGI}) {
$newQ ||= sub { CGI-new; };
}
else {
die Need CGI.pm or Apache::Request to operate;
}
--
But shouldn't Apache::Request be Apache::RequestRec?
Sincerely,
Jie
Re: uwinnipeg site down (ppm installation)?
On Thu, 31 Jul 2003, Jean-Sebastien Guay wrote: Ok, now the site seems to be back up (it responds to pings, whereas it didn't before) but trying to add it to ppm gives this: ppm rep add Apache http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58 Error: Unexpected Content-Type '' returned Does anyone know of a mirror? please? :-) Sorry about this - I had a hard disc crash, and am just in the process of restoring things. Computers are getting too smart - they know when you're vulnerable, and will act accordingly ... Hopefully it'll be ready in a day. best regards, randy
Re: need your help to test mod_perl with perl-5.8.1-RC3
Here is what happens:
MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a
by product and never was intented to be installed. Request.so was statically
linking libapreq.a into it.
Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so
is linked, it links libapreq.so dynamically, and of course it can't resolve it
later when loading.
This patch fixes things for me in libapreq and works with MM 6.03 and 6.12.
Steve, please confirm that it works for you and I'll commit it.
However Michael may want to do something else about it, since the two versions
don't do the same thing. And other people may have similar problems.
Index: Cookie/Makefile.PL
===
RCS file: /home/cvs/httpd-apreq/Cookie/Makefile.PL,v
retrieving revision 1.5
diff -u -r1.5 Makefile.PL
--- Cookie/Makefile.PL 3 Apr 2001 19:24:08 - 1.5
+++ Cookie/Makefile.PL 31 Jul 2003 11:31:06 -
@@ -27,7 +27,7 @@
@mm_args,
'INC' = -I../c . $src-inc,
'TYPEMAPS' = $src-typemaps,
-'LIBS' = -L$root -lapreq,
+'OBJECT' = Cookie.o $root/libapreq.a,
'dynamic_lib' = {
'OTHERLDFLAGS' = $src-otherldflags,
},
Index: Request/Makefile.PL
===
RCS file: /home/cvs/httpd-apreq/Request/Makefile.PL,v
retrieving revision 1.5
diff -u -r1.5 Makefile.PL
--- Request/Makefile.PL 3 Apr 2001 19:24:09 - 1.5
+++ Request/Makefile.PL 31 Jul 2003 11:31:06 -
@@ -27,7 +27,7 @@
@mm_args,
'INC' = -I../c . $src-inc,
'TYPEMAPS' = $src-typemaps,
- 'LIBS' = -L$root -lapreq,
+ 'OBJECT' = Request.o $root/libapreq.a,
'dynamic_lib' = {
'OTHERLDFLAGS' = $src-otherldflags,
},
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. It seems likely that if my build ever got as far as trying to build Request.dll then it would fail without your patch, and your patch would fix that bit, but at the moment I'm not getting that far. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. I think the cause is the same. MM 6.12 builds the shared object of libapreq (dll in your case and .so in mine), and it didn't use to do that. It seems likely that if my build ever got as far as trying to build Request.dll then it would fail without your patch, and your patch would fix that bit, but at the moment I'm not getting that far. Let me see if I can make it skip building the shared object with 6.12, which will resolve the problem for you as well. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. I think the cause is the same. MM 6.12 builds the shared object of libapreq (dll in your case and .so in mine), and it didn't use to do that. OK, try this patch: Index: c/Makefile.PL === RCS file: /home/cvs/httpd-apreq/c/Makefile.PL,v retrieving revision 1.7 diff -u -r1.7 Makefile.PL --- c/Makefile.PL 3 Apr 2001 19:24:12 - 1.7 +++ c/Makefile.PL 31 Jul 2003 13:20:35 - @@ -18,7 +18,7 @@ WriteMakefile( #grr, problems with things finding libapreq.so, sort out later. 'LINKTYPE' = 'static', -# 'SKIP' = [qw(dynamic_lib dynamic_bs)], + 'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)], 'NAME' = 'libapreq', 'INC'= $src-inc, 'TYPEMAPS' = $src-typemaps, __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Here is what happens:
MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a
was just a by product and never was intented to be installed.
Request.so was statically linking libapreq.a into it.
Now with 6.12 it creates both libapreq.so and libapreq.so, so
when Request.so is linked, it links libapreq.so dynamically, and
of course it can't resolve it later when loading.
This patch fixes things for me in libapreq and works with MM 6.03
and 6.12. Steve, please confirm that it works for you and I'll
commit it.
No, it doesn't fix it :-(
My problem sounds a little different to yours. You talk above
about ... when Request.so is linked..., but my build process
doesn't get that far.
Under MM 6.03 it used to build libapreq.lib, then Request.dll then
Cookie.dll.
Now, under MM 6.12, it builds libapreq.lib, then falls over
(boot_libapreq unresolved) when trying to build libapreq.dll.
I think the cause is the same. MM 6.12 builds the shared object of
libapreq (dll in your case and .so in mine), and it didn't use to
do that.
OK, try this patch:
No, still doesn't fix it :-(
Doesn't seem to make any difference, actually. It still tries to
build libapreq.dll, and still fails in the same way. I've attached
the c/Makefile that was generated by the patched c/Makefile.PL (which
should have skipped the dynamic_* bits, but seems not to have done).
But it never received the SKIP argument, from your Makefile:
# MakeMaker Parameters:
# INC = q[ -IC:/apache/include
-IC:/apache/include/../os/win32
-IC:/Temp/mod_perl-1.28/src/modules/perl ]
# NAME = q[libapreq]
# OBJECT = q[apache_request.o apache_cookie.o
apache_multipart_buffer.o]
# TYPEMAPS = [q[C:/Temp/mod_perl-1.28/src/modules/perl/typemap]]
# VERSION = q[1.2]
ah, of course c/Makefile.PL has a special case for WIN32. Try this:
G.
OK, that's better, but it now falls over saying don't know how to make
'dynamic'!
This patch finally fixes it for me:
--- Makefile.PL.orig2001-04-03 20:24:12.0 +0100
+++ Makefile.PL2003-07-31 15:17:03.0 +0100
@@ -18,7 +18,7 @@
WriteMakefile(
#grr, problems with things finding libapreq.so, sort out later.
'LINKTYPE' = 'static',
-# 'SKIP' = [qw(dynamic_lib dynamic_bs)],
+ 'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'NAME' = 'libapreq',
'INC' = $src-inc,
'TYPEMAPS' = $src-typemaps,
@@ -67,6 +67,8 @@
WriteMakefile('NAME' = 'libapreq',
'TYPEMAPS' = [ $ENV{MP_INC}/typemap ],
'VERSION' = $myVERSION,
+'LINKTYPE' = 'static',
+'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'OBJECT' = @objs,
'INC' = qq{ -I$ENV{AP_INC}
-I$ENV{AP_INC}/../os/win32 -I$ENV{MP_INC} },
);
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote: This patch finally fixes it for me: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. -- You're the sickest teenager I've ever set my wallet on.
