[win32] install mod_perl via ppm
With different combinations of Perl and mod_perl versions, it can get confusing when installing mod_perl on Win32 via ppm in figuring out the right one to use. To help alleviate some of this, I've made up a script - mpinstall, accessible (soon) through the install docs in the Win32 OS specific sections of http://perl.apache.org/. This will take you through a dialogue, based on your configuration info, to determine and then install the appropriate mod_perl ppm package. It will also get and copy mod_perl.so to your relevant Apache modules directory - this is currently supposed to be done via a post-install script within ppm, but this functionality appears broken with ppm3. If you try this, please let me know of any problems. -- best regards, randy kobes
Re: Shroud+ Perl obfuscator....
Hi all, On Sat, 21 Dec 2002, kyle dawkins wrote: Are you for real? [snip] You may not know this, but...[snip] Er, I think you'd better have a look at the Camel Book before you dig yourself any deeper into that particular hole. :) And I really don't think this discussion should go any further on the mod_perl List than it already has. 73, Ged.
Re: Shroud+ Perl obfuscator....
From: Randal L. Schwartz [EMAIL PROTECTED] Andrzej I extended Robert Jones' Perl Obfuscator, Shroud into what I Andrzej am calling Shroud+. I needed it to protect some rather Andrzej extensive scripts I have developed for Inventory and Image Andrzej Gallery management on client web sites. I just want to go on the record to say that I consider your action personally offensive and ethically questionable. Yep, if we could just make all those damn consultants, book authors, and training professionals give away all their work for free whether they choose to or not But then we wouldn't need the Artistic license. -- Les Mikesell [EMAIL PROTECTED]
2 proxying and mod_perl questions
Hi - I have 2 questions, one might be off topic for the list, so please be gentle about it - seems to have been a rough week for OT posters here. Anyway my situation is this: I want to do a reverse proxy of an external site using Apache: VirtualHost prague ProxyRequests on ProxyPass / http://www.externalsite.com ProxyPassReverse / http://www.externalsite.com ServerName prague /VirtualHost This works fine AFICT except if there is a page on the remote site that has a form or other link that uses POST. The maybe off-topic question is: Is this documented anywhere? I haven't been able to find a good explanation why this is. Is there a workaround? I should note that I am using mod_proxy rather than mod_rewrite because it is my (possibly incorrect) understanding that requests proxied via mod_rewrite will not end up in my local logs. I haven't actually tested that yet, but in this case I strongly prefer to have a record of the request in the logs. If mod_rewrite would leave me a record in the logs and solve the POST issue, then that is probably an acceptable workaround. Anyway, pointers to help or explanations on this question are welcomed. More on topic for this list is this question: I would like the local server to examine the HTML for the remote server and possibly modify it before sending it to the client. I would like to write a mod_perl handler for this, but I am not sure which phase I should do it at. [time passes ...] Oh wait, I see there is a section in the Eagle book (p 374) that shows how to do that - are there any gotchas or more modern examples I should know about? Thanks in advance! GV
Install Problem: make test: modules/src.t
When I 'make test' I'm getting failures relating to modules/src.t Can anyone help? -- PLATFORM -- OS: Slackware Linux 2.2.16 Perl: 5.6.0 mod_perl: 1.27 Apache: Apache/1.3.12 (Unix) PHP/4.2.3 Apache root:/var/lib/apache mod_perl build dir: /var/lib/apache/mod_perl-1.27 -- PROBLEM OCCURRENCE -- $ perl Makefile.PL \ EVERYTHING=1 APACHE_PREFIX=/var/lib/apache USE_APACI=1 Configure mod_perl with ../src ? [y] y Shall I build httpd in ../src for you? [y] y $ make Everything is good until I run the tests :-/ $ make test TEST_VERBOSE=1 --snip-- dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 FAILED tests 3-5 Failed 3/6 tests, 50.00% okay --snip-- Failed Test Status Wstat Total Fail Failed List of failed --- modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay. make: *** [run_tests] Error 29
RE: Install Problem: make test: modules/src.t
Hi - I had testing problems a few weeks ago... be sure you test as a 'normal' user, not 'root'. If you did the make under root, be sure to change user:group ownership of the entire mod_perl tree before logging in and testing. I'm _not_ an expert, but that's what happened to me :) Aloha = Beau. -Original Message- From: Mark Hawkes [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 21, 2002 12:00 PM To: [EMAIL PROTECTED] Subject: Install Problem: make test: modules/src.t When I 'make test' I'm getting failures relating to modules/src.t Can anyone help? -- PLATFORM -- OS: Slackware Linux 2.2.16 Perl: 5.6.0 mod_perl: 1.27 Apache: Apache/1.3.12 (Unix) PHP/4.2.3 Apache root:/var/lib/apache mod_perl build dir: /var/lib/apache/mod_perl-1.27 -- PROBLEM OCCURRENCE -- $ perl Makefile.PL \ EVERYTHING=1 APACHE_PREFIX=/var/lib/apache USE_APACI=1 Configure mod_perl with ../src ? [y] y Shall I build httpd in ../src for you? [y] y $ make Everything is good until I run the tests :-/ $ make test TEST_VERBOSE=1 --snip-- dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 FAILED tests 3-5 Failed 3/6 tests, 50.00% okay --snip-- Failed Test Status Wstat Total Fail Failed List of failed --- modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay. make: *** [run_tests] Error 29
Re: Shroud+ Perl obfuscator....
And if they do have something to protect, they should put their thinking caps on and realize that this sort of security is called obfuscation for a reason: it does not accomplish anything except to make the results hard to read. If you're giving away or selling the perl source, obfuscating it doesn't have any significant effect. I beg to differ. Crypt::License turns the perl source into a non-text file that appears to be pure binary when you try to open it. There is less info readable than you would find in the average C object. That is what is distributed to the target machines for execution. Only the decrypt engine can decode the file in the presence of the necessary key ... and then, it goes directly into the perl intrepreter. Sure, a clever person could recover it at that point, but the point of most of these exercises is to make it not convenient or cost effective to do so. It works quiet nicely with mod_perl as well as autoloadable modules Michael
web link broken when access cgi-bin
Dear mod_perl reader or user: Is the other webiste's link to access mysite's file or photo(jpg), not by hypertext but by cgi perl call(that function will show jpg pic) img src=http://www.mycomapny.com/cgi-bin/showphoto.pl; but it turn out cannot access(I also try /usr/bin/perl /usr/lib/cgi-bin/showphot.pl , it turn out is a dump kind's output, then I mytest.jpg then at netscape 7 URL, I type /home/enduser/mytest.jpg it showed: The image file:///home/enduser/mytest.jpg cannot be displayed, because it contains errors ) related to mod_perl did not configure or load well?(the locataion of picture suppose to be showed redcrss in IE6, or square white in mozilla) I am using apache 1.3.26 and perl 5.8 please help -- Sincere Eric www.linuxspice.com linux pc for sale
Re: 2 proxying and mod_perl questions
Hi George - I want to do a reverse proxy of an external site using Apache: VirtualHost prague ProxyRequests on You will want to set ProxyRequests off for a reverse proxy, otherwise someone could use you as a forward proxy to get to someplace else. ProxyPass / http://www.externalsite.com ProxyPassReverse / http://www.externalsite.com Not sure if it matters, but might need a trailing slash on those, i.e.: ProxyPass/ http://www.externalsite.com/ ProxyPassReverse / http://www.externalsite.com/ ServerName prague /VirtualHost This works fine AFICT except if there is a page on the remote site that has a form or other link that uses POST. Have you looked at the URL specified in the form ACTION to see if it is an absolute URL? For example, suppose I point my browser at http://www.george.com/showform.html. Your proxy then sends me the content of http://www.externalsite.com/showform.html. If the form on that page POSTs to http://www.externalsite.com/cgi-bin/form.cgi; (instead of /cgi-bin/form.cgi), then when I submit I will go directly to www.externalsite.com and bypass your proxy. The same would be true of any URL in the site that is specified absolute rather then relative. The maybe off-topic question is: Is this documented anywhere? I haven't been able to find a good explanation why this is. Is there a workaround? You would need to rewrite any URLs in the page before you send it to the browser, to either turn them into relative URLs, or to point them to www.george.com instead of www.externalsite.com. I'm pretty sure you can't do that with mod_proxy or mod_rewrite alone (although I have seen people do some crazy stuff with mod_rerwite). I should note that I am using mod_proxy rather than mod_rewrite because it is my (possibly incorrect) understanding that requests proxied via mod_rewrite will not end up in my local logs. I have not found that to be the case. Larry Leszczynski [EMAIL PROTECTED]
RE: Install Problem: make test: modules/src.t
Thanks Beau, but that didn't solve anything :-( 'make test' needs to run as root or it can't write to the Apache directory. At 12:10 2002-12-21 -1000, you wrote: Hi - I had testing problems a few weeks ago... be sure you test as a 'normal' user, not 'root'. If you did the make under root, be sure to change user:group ownership of the entire mod_perl tree before logging in and testing. I'm _not_ an expert, but that's what happened to me :) Aloha = Beau. -Original Message- From: Mark Hawkes [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 21, 2002 12:00 PM To: [EMAIL PROTECTED] Subject: Install Problem: make test: modules/src.t When I 'make test' I'm getting failures relating to modules/src.t Can anyone help? -- PLATFORM -- OS: Slackware Linux 2.2.16 Perl: 5.6.0 mod_perl: 1.27 Apache: Apache/1.3.12 (Unix) PHP/4.2.3 Apache root:/var/lib/apache mod_perl build dir: /var/lib/apache/mod_perl-1.27 -- PROBLEM OCCURRENCE -- $ perl Makefile.PL \ EVERYTHING=1 APACHE_PREFIX=/var/lib/apache USE_APACI=1 Configure mod_perl with ../src ? [y] y Shall I build httpd in ../src for you? [y] y $ make Everything is good until I run the tests :-/ $ make test TEST_VERBOSE=1 --snip-- dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 FAILED tests 3-5 Failed 3/6 tests, 50.00% okay --snip-- Failed Test Status Wstat Total Fail Failed List of failed --- modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay. make: *** [run_tests] Error 29
RE: Install Problem: make test: modules/src.t
Hi Mark - Gee, Stas told me I _had_ to be a normal user for 'make test' - and it worked...??? Wait ... I'm talking mod_perl 2 - are you installing 1? Yea, I see that in your orig. msg. Sorry - I haven't played with mod_perl 1. But - is there a testing error_log? Can you run the failed tests alone in -v mode? For mod_perl 2 you can say: t/TEST -v testname. Sorry I'm not much help... Aloha = Beau. -Original Message- From: Mark Hawkes [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 21, 2002 2:19 PM To: [EMAIL PROTECTED] Subject: RE: Install Problem: make test: modules/src.t Thanks Beau, but that didn't solve anything :-( 'make test' needs to run as root or it can't write to the Apache directory. At 12:10 2002-12-21 -1000, you wrote: Hi - I had testing problems a few weeks ago... be sure you test as a 'normal' user, not 'root'. If you did the make under root, be sure to change user:group ownership of the entire mod_perl tree before logging in and testing. I'm _not_ an expert, but that's what happened to me :) Aloha = Beau. -Original Message- From: Mark Hawkes [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 21, 2002 12:00 PM To: [EMAIL PROTECTED] Subject: Install Problem: make test: modules/src.t When I 'make test' I'm getting failures relating to modules/src.t Can anyone help? -- PLATFORM -- OS: Slackware Linux 2.2.16 Perl: 5.6.0 mod_perl: 1.27 Apache: Apache/1.3.12 (Unix) PHP/4.2.3 Apache root:/var/lib/apache mod_perl build dir: /var/lib/apache/mod_perl-1.27 -- PROBLEM OCCURRENCE -- $ perl Makefile.PL \ EVERYTHING=1 APACHE_PREFIX=/var/lib/apache USE_APACI=1 Configure mod_perl with ../src ? [y] y Shall I build httpd in ../src for you? [y] y $ make Everything is good until I run the tests :-/ $ make test TEST_VERBOSE=1 --snip-- dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 FAILED tests 3-5 Failed 3/6 tests, 50.00% okay --snip-- Failed Test Status Wstat Total Fail Failed List of failed --- - --- modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay. make: *** [run_tests] Error 29
