Re: [error] Can't locate CGI.pm in @INC
On Thu, May 29, 2003 at 04:12:51PM +1000, Stas Bekman wrote: Brown, Jeffrey wrote: Problem solved! You all are a fantastic resource to newbies! Jeff -Original Message- From: Ed [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:28 PM To: Brown, Jeffrey; [EMAIL PROTECTED] On Wed, May 28, 2003 at 09:11:06PM -0700, Brown, Jeffrey wrote: Here are the results from the log file: [Wed May 28 20:50:21 2003] [error] No such file or directory at /htdocs/perl/first.pl line 6 during global destruction. openbsd's httpd is chrooted. Again, can someone please post a patch/addition for the troubleshooting.pod doc explaining the problem and the solution in details. I've seen this kind of questions more than once here. Should go into OpenBSD cat at: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#OS_Specific_Notes Get the pod by clicking on the [src] button. For the list archive: - rtfm -u disables chroot. httpd(8) http://www.openbsd.org/faq/faq10.html#httpdchroot - set up chroot basics The doc for setting up an anoncvs mirror could be adapted for mod_perl. http://www.openbsd.org/anoncvs.shar Ofcourse much of it doesn't apply, but the part about ld.so, etc. is helpful. - List archives dreamwvr figured out how to actually get things to work and posted notes to the list. (so see archives) - 3.3-current (soon to be 3.4) And one last bit added after 3.3 was released, Revision 1.7 to apachectl: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/support/apachectl pick's up httpd_flags from /etc/rc.conf, so you can just add -DSSL -u to httpd_flags. - ports The openbsd ports system is not by default configured to install perl modules or packages in the chroot environment. You would have to set PREFIX or LOCALBASE. see bsd.port.mk(5) and ports(7) (PHP ports are set up for chroot installs). - goolge A nice HOWTO run mod_perl chrooted would be nice. maybe someone's already written it? I hope this helps some. Ed.
RE: Large Data Set In Mod_Perl
perhaps something such as copying the whole 800,000 rows to memory (as a hash?) on apache startup? That would be the fastest by far, but it will use a boatload of RAM. It's pretty easy to try, so test it and see if you can spare the RAM it requires. Always one of my favorite solutions to this sort of problem (dumb and fast) but in mod_perl won't this eat RAM x number of mod_perl threads??? In this case one of the advantages of the DBMS is that it is one copy of the data that everyone shares. mma
RE: Can't use sendmail more than once
I have migrated my site from IIS and Active State to Apache 1.3 and mod_perl on a Windows machine. I use the site to send emails to registered users using Mail::sendmail through our SMTP server (another machine). With Apache I can only send emails once after I start the Apache server, thereafter it tells me it can't connect to the SMTP server. Restarting the Apache server leads to again being able to only send emails once. I've been having similar problems using Mail::Sendmail 0.79 w/Apache 2.0.45 and mod_perl 1.99.10_dev on Windows. It works for a while (generally more than once) and then it can't connect. I haven't tracked it down yet. mma
RE: Large Data Set In Mod_Perl
On Thu, 2003-05-29 at 11:59, Marc M. Adkins wrote: perhaps something such as copying the whole 800,000 rows to memory (as a hash?) on apache startup? That would be the fastest by far, but it will use a boatload of RAM. It's pretty easy to try, so test it and see if you can spare the RAM it requires. Always one of my favorite solutions to this sort of problem (dumb and fast) but in mod_perl won't this eat RAM x number of mod_perl threads??? No. If you load the data during startup (before the fork) it will be shared unless you modify it. - Perrin
FW: Large Data Set In Mod_Perl
On Thu, 2003-05-29 at 11:59, Marc M. Adkins wrote: perhaps something such as copying the whole 800,000 rows to memory (as a hash?) on apache startup? That would be the fastest by far, but it will use a boatload of RAM. It's pretty easy to try, so test it and see if you can spare the RAM it requires. Always one of my favorite solutions to this sort of problem (dumb and fast) but in mod_perl won't this eat RAM x number of mod_perl threads??? No. If you load the data during startup (before the fork) it will be shared unless you modify it. That's news to me (not being facetious). I was under the impression that cloning Perl 5.8 ithreads cloned everything, that there was no sharing of read-only data. mma
RE: Large Data Set In Mod_Perl
On Thu, 2003-05-29 at 12:59, Marc M. Adkins wrote: That's news to me (not being facetious). I was under the impression that cloning Perl 5.8 ithreads cloned everything, that there was no sharing of read-only data. We're not talking about ithreads here, just processes. The data is shared by copy-on-write. It's an OS-level feature. See the mod_perl docs for more info. My original comment was regarding threads, not processes. I run on Windows and see only two Apache processes, yet I have a number of Perl interpreters running in their own ithreads. My understanding of Perl ithreads is that while the syntax tree is reused, data stored in the parent ithread is cloned. In addition, since I'm on Windows, I'm not convinced that the type of OS-level code sharing you're talking about is in fact done. Windows doesn't fork(). mma
file upload object - getting form field name
I need to get the form field name from a form upload.
I've been using the upload object and looping through
my uploads:
foreach my $upload ($r-upload) {
# do stuff
}
The first form has 10 fields (labeled
upload1-upload10). For a quick hack I simply used a
counter and all was good:
my $upload_id = 0;
foreach my $upload ($r-upload) {
$upload_id++;
# do stuff
}
However, the next page will display the results of the
upload...all the good images uploaded, and a bad image
icon for the ones that didn't meet the upload criteria
(size, type, etc). The images maintain their original
order.
At this point the user is allowed to reupload new
images to replace the bad images (the is an upload
button on for each bad image, not for good images).
Now my counter fails, as if the user tries to replace
upload3 (and that's the only one that is bad), my
counter thinks it's upload1 and replaces the wrong
image.
Is there a way to get the field name...I didn't see
this in the cookbook or the archives...
Thanks.
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
RE: Large Data Set In Mod_Perl
On Thu, 2003-05-29 at 13:10, Marc M. Adkins wrote: My original comment was regarding threads, not processes. I run on Windows and see only two Apache processes, yet I have a number of Perl interpreters running in their own ithreads. My understanding of Perl ithreads is that while the syntax tree is reused, data stored in the parent ithread is cloned. Remember, this is an OS-level feature. Perl doesn't have to do anything. The OS keeps track of the fact that the pages in memory have not been touched since they were copied and doesn't actually bother to copy them. In addition, since I'm on Windows, I'm not convinced that the type of OS-level code sharing you're talking about is in fact done. Windows doesn't fork(). It's not about forking, it's about having a modern virtual memory system. Windows definitely has this feature. - Perrin
Apache::MP3
Title: Apache::MP3 Has anyone gotten Apache::MP3 to run on Mod_perl 2?
Re: MOD_PERL 2.0?
On Thu, 29 May 2003, FARRINGTON, RYAN wrote: -- I don;t know if the first message was sent but here it is again -- just as a test I used the ALL in ONE package to get this installed and it works like a champ except for Apache::compat errors with something about line 68. =( I don't have the error infront of me but it is something like method not defined. It would help to know - what operating system you're using, - what minimal script and configuration set off the error, - what the error was. -- best regards, randy kobes
libapreq-1.1 SEGV's on AIX
I've seen other posts mentioning this, but no solutions. I am trying to compile libapreq-1., on AIX 5.1, with perl-5.8.0 compiled with gcc 3.3. GCC 3.3 was the only thing that I could get to compile perl on AIX without failing any tests. When I try to compile libapreq-1.1, I get: rm -f ../blib/arch/auto/Apache/Request/Request.so LD_RUN_PATH=/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request/../blib/arch/auto/libapreq gcc -Wl,-bhalt:4 -Wl,-bM:SRE -Wl,-bI:/opt/public/perl/lib/5.8.0/aix/CORE/perl.exp -Wl,-bE:Request.exp -Wl,-bnoentry -lc Request.o -bI:/.../dce.ccs.ornl.gov/fs/.rw/prod/rs_aix51/usr/local/perl/lib/site_perl/5.8.0/aix/auto/Apache/mod_perl.exp -o ../blib/arch/auto/Apache/Request/Request.so -L/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request/../blib/arch/auto/libapreq -lapreq gcc: `-b' must come at the start of the command line make[1]: *** [../blib/arch/auto/Apache/Request/Request.so] Error 1 make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request' make: *** [subdirs] Error 2 I fix this by adding '-Wl,' before the '-bI:'. I assume this is because I compiled with gcc and it needs the '-Wl,' directive. Then I get a bunch of undefined symbols so I add '-Wl,-bI:.../apache/libexec/httpd.exp'. This takes care of the problem and everything compiles cleanly. However, the make test fails: make[1]: Entering directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/c' make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/c' make[1]: Entering directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request' make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request' make[1]: Entering directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Cookie' make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf make: *** [start_httpd] Segmentation fault (core dumped) I've tried different compilers with libapreq and perl, and I've tried mod_perl built in and as a DSO. All seem to lead me to the same place. I can run simple perl scripts under mod_perl, but non that use libapreq. Here are the particulars of my perl: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=aix, osvers=5.1.0.0, archname=aix uname='aix cheetah1617 1 5 000fd42f4c00 ' config_args='-des -Dcc=gcc -Dprefix=/opt/public/perl -Dlibpth=/lib /usr/lib /usr/ccs/lib -Dlocincpth=/opt/public/gnu/include -Uloclibpth -Uinstallusrbinperl' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -fno-strict-aliasing -D_LARGE_FILES', optimize='-O', cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -fno-strict-aliasing' ccversion='', gccversion='3.3', gccosandvers='aix5.1.0.0' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -Wl,-brtl -Wl,-b32' libpth=/lib /usr/lib /usr/ccs/lib libs=-lbind -lnsl -lgdbm -ldbm -ldl -lld -lm -lc -lcrypt -lbsd -lPW perllibs=-lbind -lnsl -ldl -lld -lm -lc -lcrypt -lbsd -lPW libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Xlinker -bE:/opt/public/perl/lib/5.8.0/aix/CORE/perl.exp' cccdlflags=' ', lddlflags=' -Wl,-bhalt:4 -Wl,-bM:SRE -Wl,-bI:$(PERL_INC)/perl.exp -Wl,-bE:$(BASEEXT).exp -Wl,-bnoentry -lc' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under aix Compiled at May 27 2003 16:37:44 @INC: /opt/public/perl/lib/5.8.0/aix /opt/public/perl/lib/5.8.0 /opt/public/perl/lib/site_perl/5.8.0/aix /opt/public/perl/lib/site_perl/5.8.0 /opt/public/perl/lib/site_perl . Thanks, Steven. -- Steven M. Carter [EMAIL PROTECTED] Oak Ridge National Laboratory
mod_perl caching form data?
[Sorry if an identical message comes through later. I don't think the list manager liked my address the first time I sent it through.] Hi all, I'm having a problem with mod_perl 1.2.7 that's baffling me completely, and I've been searching and reading for days, but I still can't figure it out. My apologies if this comes up frequently. I did try rather lengthy searches through the mailing list archives. Right now, I'm using mod_perl 1.2.7 compiled into an apache 1.3.27 server running on a Solaris 9 (semi-current patches, though I can't imagine that that's relevant) server. I've written some fairly straight-forward mod_perl scripts (using CGI.pm). They take form data from the user, process it, and stick it in a database (through DBI). So far, so good. Everything works pretty well... Except that something's caching previously entered form data and displaying it back to me as the default values in those same forms. As an example, this form has a text field that asks for IP addresses, and the text input will occasionally be filled out with the IP address of a system that you had entered a few minutes ago. Naturally, I suspected that my browser was the guilty party, even though I had specified '-1d' as the expiration time in the CGI header() command. It turns out that this is not the case. The forms will occasionally be pre-filled out with IP addresses that other people have given! I even went so far as to set up a network sniffer to verify that the server was indeed setting (in the HTML it sent to the client) the value parameter of the text fields to an IP address that another user had previously entered. Needless to say, my script is *not* setting the default or value parameters for these text fields. As an uneducated guess, I'd say that each httpd child-process is automatically filling out forms with data that it itself has previously received, but that's only a guess, and it still doesn't get me any closer to figuring out why it's happening. Can anyone offer any assistance or point me somewhere that I could find some documentation on what's happening? I'm completely baffled. Thanks! David
Re: mod_perl caching form data?
Quoting David Ressman [EMAIL PROTECTED]: something's caching previously entered form data and displaying it back to me as the default values in those same forms. As an example, this form has a text field that asks for IP addresses, and the text input will occasionally be filled out with the IP address of a system that you had entered a few minutes ago. If you do a view source in the browser, and check the form fields, do they have the VALUE=... paramters set? ie do you see something like this: input type=text name=ipaddress value=192.168.1.1 If that value=192.168.1.1 is set in any of your form fields, then your script is the cuprit. If your form fields don't have the value=192.168.1.1 set, or it is set to value=, then your browser is the culprit. Most modern browsers will offer to remember values you have entered into a form. On subsequent visits to the same URL, the values will be prefilled by the browser for you. mod_perl itself will never prefill form values for you. It is completely up to your script (or the modules it uses) to munge the data coming through. It is possible that you are creating your form fields with CGI.pm, which will use the currently POSTed parameters to prefill the form, or if you are using a module like HTML::FillInForm, which will also prefill form fields. But you would have to explicitly use these features in your script. HTH Cees,
Re: mod_perl caching form data?
Thus spake Cees Hek ([EMAIL PROTECTED]): input type=text name=ipaddress value=192.168.1.1 If that value=192.168.1.1 is set in any of your form fields, then your script is the cuprit. If your form fields don't have the value=192.168.1.1 set, or it is set to value=, then your browser is the culprit. That's just the problem. The value= parameter *is* filled out (and it is being done at the server end as evidenced by the network sniffer.) Unfortunately, my script is not doing it. Here's what I have in the script: print IP Address: , $cgi-textfield(-name='ipaddress', -size=20, -maxlength=20), $cgi-p; But yet the form is filled out when I go to it with a web browser. Most modern browsers will offer to remember values you have entered into a form. On subsequent visits to the same URL, the values will be prefilled by the browser for you. I was certain that that's what it was, but it just can't be. I've even used browsers on computers that have never been to the site before and the data is still pre-filled out. mod_perl itself will never prefill form values for you. It is completely up to your script (or the modules it uses) to munge the data coming through. That's good to know. Thanks very much. It is possible that you are creating your form fields with CGI.pm, which will use the currently POSTed parameters to prefill the form, or This sounds like the most likely culprit, even though I haven't explicitly turned anything on. It's possible that I've done it inadvertently. I'll check it out. Thanks again for your help. David
Re: mod_perl caching form data?
Quoting David Ressman [EMAIL PROTECTED]: It is possible that you are creating your form fields with CGI.pm, which will use the currently POSTed parameters to prefill the form, or This sounds like the most likely culprit, even though I haven't explicitly turned anything on. It's possible that I've done it inadvertently. I'll check it out. Read the CGI.pm docs and you will find the cause of your problem: http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm#CREATING_FILL_OUT_FORMS_ Cheers, Cees
Re: mod_perl caching form data?
On Thu, 2003-05-29 at 16:40, David Ressman wrote: That's just the problem. The value= parameter *is* filled out (and it is being done at the server end as evidenced by the network sniffer.) Unfortunately, my script is not doing it. Here's what I have in the script: print IP Address: , $cgi-textfield(-name='ipaddress', -size=20, -maxlength=20), $cgi-p; CGI.pm uses sticky widgets by default. These are supposed to be cleared between requests though, by a cleanup handler that CGI.pm uses. Are you using mod_perl 2, by any chance? I think I see a bug in CGI.pm's handling of this for mod_perl 2. It's looking for Apache-request, which doesn't work unless you have Apache::compat on. You might also run into problems if you are copying the CGI object into a global or accidentally creating a closure with it. If you can post a very small test case that exhibits the problem, we can probably tell you if you have either of those issues. - Perrin
how to secure perl modules?
i have a collection of perl modules (running under the mod_perl umbrella) and would like to distribute the application to several different sources (clients with open internet web servers). but i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. what options do i have (if any) to secure the code so that it can't be 'easily' stolen? 'easily' being the operative word here, as i realize it wont be 100% safe no matter what i do. the ideal would be to perhaps encrypt some of the code, maybe a few of the base configuration modules, maybe even the startup.pl file, others? any suggestions would be appreciated, thanks
Re: mod_perl caching form data?
Thus spake Perrin Harkins ([EMAIL PROTECTED]):
CGI.pm uses sticky widgets by default. These are supposed to be cleared
between requests though, by a cleanup handler that CGI.pm uses. Are you
using mod_perl 2, by any chance? I think I see a bug in CGI.pm's
Nope. mod_perl 1.27
But... you and Cees are beautiful people. I'd read almost completely
through the CGI.pm documentation, but I didn't remember that it was
significant that each http child only compiles the code once, so these
cgi parameters might stay in memory as new clients hit the children.
A simple $cgi-delete('ipaddress') to delete the value when I create
the field has done the trick. Thanks very much to the both of you.
Re: how to secure perl modules?
hi ( 03.05.29 14:25 -0700 ) Kirk Rogers: but i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. why not? have you ever read the GNU manifesto? http://www.gnu.org/gnu/manifesto.html and how do you know it won't be a script kiddie, or middle manager, or someone just like you [but a little less experienced] that 'steals' it? any suggestions would be appreciated license it under GPL and count it as a donation to the good of the species. or, if you're more self-directed, a step toward release from the endless cycle of death and rebirth. -- \js
RE: how to secure perl modules?
why the scarcasm? -Original Message- From: John Saylor [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 2:34 PM To: [EMAIL PROTECTED] Cc: modperl Subject: Re: how to secure perl modules? hi ( 03.05.29 14:25 -0700 ) Kirk Rogers: but i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. why not? have you ever read the GNU manifesto? http://www.gnu.org/gnu/manifesto.html and how do you know it won't be a script kiddie, or middle manager, or someone just like you [but a little less experienced] that 'steals' it? any suggestions would be appreciated license it under GPL and count it as a donation to the good of the species. or, if you're more self-directed, a step toward release from the endless cycle of death and rebirth. -- \js
Re: mod_perl caching form data?
On Thu, 2003-05-29 at 17:26, [EMAIL PROTECTED] wrote:
A simple $cgi-delete('ipaddress') to delete the value when I create
the field has done the trick. Thanks very much to the both of you.
I'm glad to hear that worked, but it's still worrisome that you were
seeing data leak between different users. The form widgets are only
supposed to be sticky for values submitted on the current request. It
indicates either a bug in the way CGI.pm clears its variables under
mod_perl or a bug in your script that could surface again later.
- Perrin
Re: how to secure perl modules?
you seem to be talking about two different things here. firstly, do you want to protect your source code being viewed by other people? secondly, do you want to ensure that your code is only being run on computers that you have authorised? these are related problems, but each requires a different method of solving it. the other question that is useful to ask is how many days of effort will be required to secure your program and compare that with how much your clients would value that amount of time being used in development of new features instead? uru -Dave Kirk Rogers wrote: i have a collection of perl modules (running under the mod_perl umbrella) and would like to distribute the application to several different sources (clients with open internet web servers). but i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. what options do i have (if any) to secure the code so that it can't be 'easily' stolen? 'easily' being the operative word here, as i realize it wont be 100% safe no matter what i do. the ideal would be to perhaps encrypt some of the code, maybe a few of the base configuration modules, maybe even the startup.pl file, others? any suggestions would be appreciated, thanks
RE: how to secure perl modules?
On Thu, 2003-05-29 at 17:41, Kirk Rogers wrote: why the scarcasm? You asked a very loaded question that is guaranteed to get you a lot angry responses on most Perl mailing lists. Hiding your source code is a FAQ (http://perldoc.com/perl5.8.0/pod/perlfaq3.html#How-can-I-hide-the-source-for-my-Perl-program-) so the real question is more whether or not the method you've chosen to hide it works with mod_perl. I believe source filters do work, although I've never tried them myself. If you search in the mail archives you'll find many long and flaming threads on the subject. Personally, I would appreciate it if everyone would let this thread die quietly unless they have something specific to add about the use of source filters (or alternate methods) with mod_perl. If you want to argue the ethics of hiding source code, please do it off the list. - Perrin
Re: how to secure perl modules?
Hi there, On Thu, 29 May 2003, Kirk Rogers wrote: i have a collection of perl modules ... i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. This is getting to be an old chestnut, I wonder if we should specifically forbid discussion of it in the email-etiquette doc.? The best way to do what you want is to code it in C, compile it and send out only the compiled executables, a bit like that firm up in the North-West USA. There are -ahem- Open Source packages to translate Perl into C and/or bytecode, but then I suppose you wouldn't get much help from this List with C programs... It does seem a bit rich to take all the free stuff you can from CPAN and then try to deny everyone else the fruits of your own labours. But I suppose it's a free world, at least in parts. 73, Ged.
Re: libapreq-1.1 SEGV's on AIX
Hi there, On Thu, 29 May 2003, Steven M. Carter wrote: There's a thread here: http://www.geocrawler.com/archives/3/182/2000/2/0/3376687/ in which Doug MacEachern says: I don`t expect libapreq (or any of the Apache:: xs modules outside of the mod_perl dist) to work under aix. it needs to point at the apache and mod_perl .exp files to link properly. I don`t have access to an aix box at the moment, maybe one of our aix experts can help here? a patch to Apache::src would be ideal so all the Apache:: xs modules on cpan can use it. the Apache:: xs modules that ship with mod_perl don`t have this problem because they are all linked static by default. I have no idea if anything ever came of this. HTH 73, Ged.
Help with Apache::httpd_conf
I am writing an apache authentication/authorization module which gets called in the Location directive outside the virtual host in the conf file. However, if a certain condition is not satisfied it redirects to secured server wherin our inhouse authentication module gets called and if the user authenticates himself, then again my authorization module (same code as my authentication module but does authorization now by reading a file). My problem is this. I need one common entry for handlers in Location directive, both inside and outside virtual host. Thus I would like to generate virtual host Location directive entry during run-time. I looked at Apache::httpd_conf () but dont understand how to implement it. I would like to have something similar to the following in the virtual host entry: Location /~xyz AuthName someauth AuthType sometype PerlAuthenHandler Apache::InHouseModule PerlAuthzHandler Apache::MyModule require valid-user PerlSetVariable something /Location Also, how do I parse /~xyz from Location directive outside virtual host. Thanks in advance for your help. Regards, Shashank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Error of $r-read failed to read
[bouncing back to the list with additional info]
Chris Faust wrote:
Ouch, in other words its going to be a tough on to track down :)..
Thanks Stas, I at least have some direction now.
what you could do is to go to the httpd source and change it to log the error.
Look in modules/http/http_protocol.c:1884
/* We lose the failure code here. This is why ap_get_client_block should
* not be used.
*/
if (rv != APR_SUCCESS) {
/* if we actually fail here, we want to just return and
* stop trying to read data from the client.
*/
r-connection-keepalive = AP_CONN_CLOSE;
apr_brigade_destroy(bb);
return -1;
}
So log it there:
if (rv != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, read failed);
/* if we actually fail here, we want to just return and
* stop trying to read data from the client.
*/
r-connection-keepalive = AP_CONN_CLOSE;
apr_brigade_destroy(bb);
return -1;
}
-Chris
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Chris Faust [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 8:15 PM
Subject: Re: Apache Error of $r-read failed to read
Chris Faust wrote:
Hi,
We have been having some problems where all of a sudden apache will
start logging the error of:
[error] mod_perl: $r-read failed to read
Multiple times (100s in less then 10th of a sec), often it will get to
the point where load on the machine goes through the roof and apache has
problems responding and it appears to be the number of requests that are
happening as limits that shouldn't be reached like DB connections and
apache processes are maxing out during non-peak hours.
From what we could see it looked like someone outside was sending all
kind of linefeeds and whatnot within the URL which was documented in the
Apache 45 release which we did update - now we are down to getting the
above mod_perl error and shortly after that starts all hell breaks
loose.
Nowhere in our code do we directly call the read method nor can I find
anything relating to the error so I'm a little lost on what I can do.
Any ideas?
You probably use CGI.pm or something else that calls $r-read(). This
happends
in xs/Apache/RequestIO/Apache__RequestIO.h (hint grep the mod_perl source
code):
/*
* XXX: as stated in ap_get_client_block, the real
* error gets lots, so we only know that there was one
*/
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
mod_perl: $r-read failed to read);
break;
As you can see from the comment due to a bad implementation of
ap_get_client_block in Apache, the error is not available. I'm planning to
rewrite all these functions to get rid of ap_get_client_block, and work
with
bucket brigades instead.
In any case that won't solve the problem that you are seeing, I'd dig in
Apache. e.g. trying to use mod_cgi (which doesn't use ap_get_client_block)
to
reproduce the problem and ask at the httpd list.
__
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: Apache::MP3
FARRINGTON, RYAN wrote: Has anyone gotten Apache::MP3 to run on Mod_perl 2? Hold on a bit, I'll post a ported version soonish. __ 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: libapreq-1.1 SEGV's on AIX
[taking this thread to the apreq-dev list, those interested please go there] Steven M. Carter wrote: I've seen other posts mentioning this, but no solutions. I am trying to compile libapreq-1., on AIX 5.1, with perl-5.8.0 compiled with gcc 3.3. GCC 3.3 was the only thing that I could get to compile perl on AIX without failing any tests. When I try to compile libapreq-1.1, I get: rm -f ../blib/arch/auto/Apache/Request/Request.so LD_RUN_PATH=/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request/../blib/arch/auto/libapreq gcc -Wl,-bhalt:4 -Wl,-bM:SRE -Wl,-bI:/opt/public/perl/lib/5.8.0/aix/CORE/perl.exp -Wl,-bE:Request.exp -Wl,-bnoentry -lc Request.o -bI:/.../dce.ccs.ornl.gov/fs/.rw/prod/rs_aix51/usr/local/perl/lib/site_perl/5.8.0/aix/auto/Apache/mod_perl.exp -o ../blib/arch/auto/Apache/Request/Request.so -L/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request/../blib/arch/auto/libapreq -lapreq gcc: `-b' must come at the start of the command line make[1]: *** [../blib/arch/auto/Apache/Request/Request.so] Error 1 make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request' make: *** [subdirs] Error 2 I fix this by adding '-Wl,' before the '-bI:'. I assume this is because I compiled with gcc and it needs the '-Wl,' directive. Then I get a bunch of undefined symbols so I add '-Wl,-bI:.../apache/libexec/httpd.exp'. This takes care of the problem and everything compiles cleanly. However, the make test fails: make[1]: Entering directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/c' make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/c' make[1]: Entering directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request' make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Request' make[1]: Entering directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Cookie' make[1]: Leaving directory `/.../dce.ccs.ornl.gov/fs/users/u003/scarter/compile/aix_51/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf make: *** [start_httpd] Segmentation fault (core dumped) I've tried different compilers with libapreq and perl, and I've tried mod_perl built in and as a DSO. All seem to lead me to the same place. I can run simple perl scripts under mod_perl, but non that use libapreq. Here are the particulars of my perl: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=aix, osvers=5.1.0.0, archname=aix uname='aix cheetah1617 1 5 000fd42f4c00 ' config_args='-des -Dcc=gcc -Dprefix=/opt/public/perl -Dlibpth=/lib /usr/lib /usr/ccs/lib -Dlocincpth=/opt/public/gnu/include -Uloclibpth -Uinstallusrbinperl' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -fno-strict-aliasing -D_LARGE_FILES', optimize='-O', cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -fno-strict-aliasing' ccversion='', gccversion='3.3', gccosandvers='aix5.1.0.0' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -Wl,-brtl -Wl,-b32' libpth=/lib /usr/lib /usr/ccs/lib libs=-lbind -lnsl -lgdbm -ldbm -ldl -lld -lm -lc -lcrypt -lbsd -lPW perllibs=-lbind -lnsl -ldl -lld -lm -lc -lcrypt -lbsd -lPW libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Xlinker -bE:/opt/public/perl/lib/5.8.0/aix/CORE/perl.exp' cccdlflags=' ', lddlflags=' -Wl,-bhalt:4 -Wl,-bM:SRE -Wl,-bI:$(PERL_INC)/perl.exp -Wl,-bE:$(BASEEXT).exp -Wl,-bnoentry -lc' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under aix Compiled at May 27 2003 16:37:44 @INC: /opt/public/perl/lib/5.8.0/aix /opt/public/perl/lib/5.8.0 /opt/public/perl/lib/site_perl/5.8.0/aix /opt/public/perl/lib/site_perl/5.8.0 /opt/public/perl/lib/site_perl . Thanks, Steven. -- __ 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
Re: Handler called second time acts up.
Ged Haywood wrote: Hi there, On Thu, 29 May 2003, Igor Rojdestvenski wrote: designed a mod_perl handler moduel [snip] works fine first time, but when I refresh it, it works differently. [snip] My theory is that something is wrong with local/global variables [snip] Check out the mod_perl Guide - you can find it on the mod_perl website, http://perl.apache.org The guide contains a wealth of information about this kind of thing. See in particular the sections about mod_perl traps, debugging, and Sometimes it works, sometimes it doesn't... Just to save you the time searching, here is the link to what Ged has mentioned: http://perl.apache.org/docs/1.0/guide/porting.html#Sometimes_it_Works__Sometimes_it_Doesn_t __ 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
how to make sure code wasn't changed
OK... I have a system I've developed for a client that is now on a central server. They would like me to make changes so it can be installed on the laptops of users to use off site if necessary. Here's my question: has anyone setup a clever way, possibly using CRC/MD5 analysis, to check to make sure code hasn't been changed? I don't care if someone steals it or gives it to their friends, but I don't want the code to yield results if it's been modified - either intentionally or on accident - because it could give false results. These are sales guys machines which (no offense to any sales people lurking on this list) means anything can and probably will happen. I realize that someone could circumvent a CRC check just by changing the CRC check number, but I'm not worried... if they are that clever kudos to them. Another option is maybe to use IndigoPerl's perl2exe and make the perl script .exe files... however, then I lose the mod_perl benefits. This may not be a big deal since only one person will be running at a time and performance shouldn't be a huge issue. Just curious if anyone has done something like this before... Thanks, Mike
Mod_Perl 2?
Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Per l/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13.
Re: Mod_Perl 2?
Ryan Farrington wrote: Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Per l/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13. http://perl.apache.org/docs/2.0/user/porting/compat.html#Code_Porting http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Line_Lookups __ 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: Mod_Perl 2?
Here is what the Command_Line_Lookups tells me: to use method 'server_root_relative' add: use Apache::ServerUtil (); here is what my .pl file looks like before I make any modifications: :: CODE :: use Apache2 (); use ModPerl::Util (); use Apache::RequestRec (); use Apache::RequestIO (); use Apache::RequestUtil (); use Apache::Server (); use Apache::ServerUtil (); use Apache::Connection (); use Apache::Log (); use Apache::Const -compile = ':common'; use APR::Const -compile = ':common'; use APR::Table (); use Apache::compat (); use ModPerl::Registry (); use CGI (); use XML::LibXML(); use XML::LibXSLT(); 1; :: END CODE :: that is it... still compiles with an error =( -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 10:10 PM To: Ryan Farrington Cc: [EMAIL PROTECTED] Subject: Re: Mod_Perl 2? Ryan Farrington wrote: Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Per l/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13. http://perl.apache.org/docs/2.0/user/porting/compat.html#Code_Porting http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Li ne_Lookups __ 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: Large Data Set In Mod_Perl
Perrin Harkins wrote: simran wrote: I need to be able to say: * Lookup the _distance_ for the planet _mercury_ on the date _1900-01-01_ On the face of it, a relational database is best for that kind of query. However, if you won't get any fancier than that, you can get by with MLDBM or something similar. Currently i do this using a postgres database, however, my question is, is there a quicker way to do this in mod_perl - would a DB_File or some other structure be better? Query speed comes into question only when there is a heavy use. Postgress has an 'Explain' facility via pgsql. Just add Explain before the query and you will get the cost of the query. By creating proper indexes you can get good optimization. What if you add a table later and you need to join that with the planet table? If you keep your planet data somewhere else, then the access becomes cumbersome as well as slower. There are many ways to speed up Postgresql. I recommend the Posgresql book by Korryand Susan Douglas. I got it from Barnes and Nobles. IMHO stay with the relational database you are on and find ways to optimize. A DBM file will be faster. What you can do is build a key out of planet + date, so that you grab the right record with a single access. Either use MLDBM for storing hashes inside each record, or just a simple join/split approach. This would be a good idea if you are implementing your tool and you know what limitations you will be subjected to. MySQL would probably also be faster than PostgreSQL for this kind of simple read-only querying, but not as fast as a DBM file. SDBM_File is the fastest DBM around, if you can live with the space limitations it has. perhaps something such as copying the whole 800,000 rows to memory (as a hash?) on apache startup? Postgresql may have a way to 'stick' a table in memory like MySQL. That would be the fastest by far, but it will use a boatload of RAM. It's pretty easy to try, so test it and see if you can spare the RAM it requires. - Perrin
MOD_PERL 2.0?
Title: MOD_PERL 2.0? just as a test I used the ALL in ONE package to get this installed and it works like a champ except for Apache::compat errors with something about line 68. =( I don't have the error infront of me but it is something like method not defined.
mod_perl caching form data?
Hi all, I'm having a problem with mod_perl 1.2.7 that's baffling me completely, and I've been searching and reading for days, but I still can't figure it out. My apologies if this comes up frequently. I did try rather lengthy searches through the mailing list archives. Right now, I'm using mod_perl 1.2.7 compiled into an apache 1.3.27 server running on a Solaris 9 (semi-current patches, though I can't imagine that that's relevant) server. I've written some fairly straight-forward mod_perl scripts (using CGI.pm). They take form data from the user, process it, and stick it in a database (through DBI). So far, so good. Everything works pretty well... Except that something's caching previously entered form data and displaying it back to me as the default values in those same forms. As an example, this form has a text field that asks for IP addresses, and the text input will occasionally be filled out with the IP address of a system that you had entered a few minutes ago. Naturally, I suspected that my browser was the guilty party, even though I had specified '-1d' as the expiration time in the CGI header() command. It turns out that this is not the case. The forms will occasionally be pre-filled out with IP addresses that other people have given! I even went so far as to set up a network sniffer to verify that the server was indeed setting (in the HTML it sent to the client) the value parameter of the text fields to an IP address that another user had previously entered. Needless to say, my script is *not* setting the default or value parameters for these text fields. As an uneducated guess, I'd say that each httpd child-process is automatically filling out forms with data that it itself has previously received, but that's only a guess, and it still doesn't get me any closer to figuring out why it's happening. Can anyone offer any assistance or point me somewhere that I could find some documentation on what's happening? I'm completely baffled. Thanks! David
how to secure perl modules?
i have a collection of perl modules (running under the mod_perl umbrella) and would like to distribute the application to several different sources (clients with open internet web servers). but i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. what options do i have (if any) to secure the code so that it can't be 'easily' stolen? 'easily' being the operative word here, as i realize it wont be 100% safe no matter what i do. the ideal would be to perhaps encrypt some of the code, maybe a few of the base configuration modules, maybe even the startup.pl file, others? any suggestions would be appreciated, thanks
Help with Apache::httpd_conf
I might have made a mistake by sending this post to docs-dev forum. Sending it again to modperl forum. --- I am writing an apache authentication/authorization module which gets called in the Location directive outside the virtual host in the conf file. However, if a certain condition is not satisfied it redirects to secured server wherin our inhouse authentication module gets called and if the user authenticates himself, then again my authorization module (same code as my authentication module but does authorization now by reading a file). My problem is this. I need one common entry for handlers in Location directive, both inside and outside virtual host. Thus I would like to generate virtual host Location directive entry during run-time. I looked at Apache::httpd_conf () but dont understand how to implement it. I would like to have something similar to the following in the virtual host entry: Location /~xyz AuthName someauth AuthType sometype PerlAuthenHandler Apache::InHouseModule PerlAuthzHandler Apache::MyModule require valid-user PerlSetVariable something /Location Also, how do I parse /~xyz from Location directive outside virtual host. Thanks in advance for your help. Regards, Shashank.
RE: mod_perl caching form data?
David Ressman wrote:
something's caching previously entered form data and
displaying it back to me as the default values in those same forms
This is most likely a variable scoping problem as described here:
http://perl.apache.org/docs/1.0/guide/frequent.html
As a rule of thumb, variables which are 'local' to a subroutine
should be declared with 'my' and variables which should be
visible to all routines in a file should be declared with 'our'.
eg:
use CGI;
our $cgi = new CGI;
...
sub do_something {
my($arg1, $arg2) = @_;
...
}
If your script has global variables which are declared with 'my',
they will cause problems.
Regards
Grant
Re: Mod_Perl 2?
Ryan Farrington wrote: Here is what the Command_Line_Lookups tells me: to use method 'server_root_relative' add: use Apache::ServerUtil (); [...] that is it... still compiles with an error =( right, the API change. Here is the correct URL: http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_server_root_relative_ Can't locate object method server_root_relative via package Apache __ 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: Mod_Perl 2?
On Thu, 29 May 2003, Ryan Farrington wrote: Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Perl/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13. Are you invoking startup.pl from the command line: C:\Apache2\conf perl startup.pl If so, this won't work - it needs to be loaded within the Apache environnment, upon starting Apache. Does Apache start OK with this startup.pl? -- best regards, randy
htaccess files
Is it possible to configure an htaccess file to
call a script using apache registry and use it in the
PerlAccessHandler.
I have written one pretty large perl script in
mod-perl using the apache registry to serve out picture gallery pages. I
would like to do some validation of my own on a per directory type
basis.
also
I was trying to run this code to do some test and
could only get it to work with the #pound signs in from of the files
directives.
It works like this.
#Files *
PerlAccessHandler 'sub {return Apache::Constants::FORBIDDEN;}' \
#/Files
but I get this error in the log file. I could not get
it to work any other way.
[Fri May 30 00:22:52 2003] [warn] Apache does not support line-end comments.
Consider using quotes around argument: "#/Files"
Thanks in advance
John Michael
Re: Help: Problems compling mod_perl-1.x-dev on FreeBSD-4.8
I'm going to follow your instructions, thank you. One question, though, since it seems you're adding args to a file that gets passed to mod_perl's build process (which in turn builds httpd): how do you add/activate other modules to apache in this manner. PHP is a DSO (for me) so that's solved. But I have some others, for example one of my config commands: ./configure \ --with-perl=/usr/local/bin/perl \ --server-gid=nogroup \ --suexec-docroot=/usr/local/apache/htdocs \ --enable-module=most \ --enable-module=auth_db \ --enable-module=mmap_static \ --enable-shared=max \ --enable-module=ssl \ --enable-rule=SHARED_CORE \ --activate-module=src/modules/dosevasive/libdosevasive.a and so forth. I may have had the build process incorrect in the beginning, where first I would run a script to do: ./configure \ --with-perl=/usr/local/bin/perl \ --server-gid=nogroup \ --suexec-docroot=/usr/local/apache/htdocs \ --enable-module=most \ --enable-module=auth_db \ --enable-module=mmap_static \ --add-module=src/modules/dosevasive/mod_dosevasive.c \ --enable-shared=max I know that certain configuration parameters need to be set before you build Apache (like the Layout, which I customize). Thanks for your help. At 12:01 PM 5/26/2003, you wrote: Hello again, Please keep it on the list. On Mon, 26 May 2003, Forrest Aldrich wrote: I'm using whatever is in CVS at the moment. The Changes file indicates this is version 1.27_01-dev. Well that *should* be OK, but I have to wonder why you're doing it that way. It can only make things more complicated. Why not just grab the latest tarballs? trying to figure out how to get it statically-linked, as opposed to DSO -- [snip] I've looked around for simple directions out there and haven't run into any. Have you not seen the Guide? Heaven knows it's mentioned enough on this List, and on the mod_perl home page at http://perl.apache.org. It's quite simple to build mod_perl statically. First you may need to stop any existing Apache - things get confusing if you accidentally try to run two at once. (They're confusing enough if you do it on purpose :). Then I'd recommend taking all the junk you now have in /usr/local/apache and hiding it someplace safe for now. I'm assuming you're building with the apache binaries, config files etc. under /usr/local/apache, but you might not be. If not then get rid of them from wherever they are. (I'd just move them, not delete them. :) Then: 0. mkdir -p /home/forrest/src 1. cd /home/forrest/src 2. tar xzvf .../mod_perl-1.27.tar.gz 3. tar xzvf .../apache_1.3.27.tar.gz 4. cd mod_perl-1.27 5. cp attached_file makepl_args.mod_perl 6. perl Makefile.PL 7. make 8. su 9. make install 10. cd ../apache_1.3.27 11. make install Now you should be able to start Apache and see a message in the error_log telling you what it was you started. Then the configuration fun begins: I have no idea if this apache will be suitable for your purposes, but it is at least a static build and I've been using Apache servers built this way for several years with never so much as an oops. 73, Ged. attached_file is just three lines: EVERYTHING=1 DO_HTTPD=1 USE_APACI=1 when you get more comfortable with it, you can start to make more complicated versions of it. When I want to archive a server build, all I keep is this file and the tarballs.
Re: htaccess files
John Michael wrote:
Is it possible to configure an htaccess file to call a script using
apache registry and use it in the PerlAccessHandler.
I have written one pretty large perl script in mod-perl using the apache
registry to serve out picture gallery pages. I would like to do some
validation of my own on a per directory type basis.
Certainly. Both the eagle and the modperl cookbook provide plenty of examples.
.htaccess is not any different from a normal httpd.conf for this purpose.
I was trying to run this code to do some test and could only get it to
work with the #pound signs in from of the files directives.
It works like this.
#Files *
PerlAccessHandler 'sub {return Apache::Constants::FORBIDDEN;}' \
#/Files
but I get this error in the log file. I could not get it to work any
other way.
[Fri May 30 00:22:52 2003] [warn] Apache does not support line-end
comments. Consider using quotes around argument: #/Files
drop \ from the end of previous line since if you have it Apache reads it as:
PerlAccessHandler 'sub {return Apache::Constants::FORBIDDEN;}' #/Files
__
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: Help: Problems compling mod_perl-1.x-dev on FreeBSD-4.8
Hi there, On Fri, 30 May 2003, Forrest Aldrich wrote: how do you add/activate other modules to apache in this manner. Here's one I prepared earlier. Use caution, this is an old one and I haven't tested it lately. The documentation is in the Eagle Book, I don't know if it's in the CookBook, my copy is distant. Geoff might tell us. 73, Ged. -- USE_APACI=1 APACHE_PREFIX=/usr/local APACHE_SRC=../apache_1.3.22/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--sbindir=/usr/local/sbin/httpd_perl APACI_ARGS=--sysconfdir=/usr/local/apache/httpd_perl/conf APACI_ARGS=--runtimedir=/usr/local/apache/httpd_perl/run APACI_ARGS=--logfiledir=/usr/local/apache/httpd_perl/logs APACI_ARGS=--localstatedir=/usr/local/apache/httpd_perl/stat APACI_ARGS=--proxycachedir=/usr/local/apache/httpd_perl/proxy APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=include APACI_ARGS=--enable-module=info APACI_ARGS=--enable-module=usertrack --
Re: mod_perl caching form data?
Hi!
On Thu, May 29, 2003 at 12:19:49PM -0500, David Ressman wrote:
So far, so good. Everything works pretty well... Except that
something's caching previously entered form data and displaying it back
to me as the default values in those same forms. As an example, this
form has a text field that asks for IP addresses, and the text input
will occasionally be filled out with the IP address of a system that
you had entered a few minutes ago.
Sounds to me like you are storing your values in global variables which
won't get reset between requests.
Do you declare you vars with 'my' ?
Are you running with
use strict;
use warnings;
? If not, turn them on, as thos pragmas will help you catch this kind of
error.
See here:
http://perl.apache.org/docs/1.0/guide/porting.html#Global_Variables_Persistence
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: how to secure perl modules?
Hi!
On Thu, May 29, 2003 at 10:27:54AM -0700, iCap wrote:
i have a collection of perl modules (running under the mod_perl umbrella)
and would like to distribute the application to several different sources
(clients with open internet web servers). but i dont want to send it out
without at least making it somewhat difficult for some hacker to just simply
steal it and load it somewhere else without my consent. what options do i
have (if any) to secure the code so that it can't be 'easily' stolen?
'easily' being the operative word here, as i realize it wont be 100% safe no
matter what i do.
the ideal would be to perhaps encrypt some of the code, maybe a few of the
base configuration modules, maybe even the startup.pl file, others?
If you want to make it hard to read the code, use an Obfuscator (eg.
Acme::EyeDrops)
If want to really secure your code: it's not possible, see this thread on
perlmonks:
http://www.perlmonks.org/index.pl?node_id=243011
or search in the mailinglist archives. This questions was discussed here a
few times.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: how to secure perl modules?
Hi All,
Just to throw a spanner in the works, a little while ago I came across the
following Article on the Net.
http://www.perl.com/pub/a/2002/10/15/radiator.html
From what I can tell The author of the 'radiator' product claims to have
successfully shipped 'encrypted' code.
I've been pondering how to do this for ages anyay, I realise it's not
completely foolproof, but I'm trying to find a mechanism that would stop
anybody but a perl litterate hacker from getting at my code.
Marty
- Original Message -
From: Thomas Klausner [EMAIL PROTECTED]
To: modperl [EMAIL PROTECTED]
Sent: Friday, May 30, 2003 8:58 AM
Subject: Re: how to secure perl modules?
Hi!
On Thu, May 29, 2003 at 10:27:54AM -0700, iCap wrote:
i have a collection of perl modules (running under the mod_perl
umbrella)
and would like to distribute the application to several different
sources
(clients with open internet web servers). but i dont want to send it
out
without at least making it somewhat difficult for some hacker to just
simply
steal it and load it somewhere else without my consent. what options do
i
have (if any) to secure the code so that it can't be 'easily' stolen?
'easily' being the operative word here, as i realize it wont be 100%
safe no
matter what i do.
the ideal would be to perhaps encrypt some of the code, maybe a few of
the
base configuration modules, maybe even the startup.pl file, others?
If you want to make it hard to read the code, use an Obfuscator (eg.
Acme::EyeDrops)
If want to really secure your code: it's not possible, see this thread on
perlmonks:
http://www.perlmonks.org/index.pl?node_id=243011
or search in the mailinglist archives. This questions was discussed here a
few times.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
RE: how to secure perl modules?
Regarding the use of source filters, they only seemed to cause me trouble under mod_perl. A while ago I tried using Switch.pm, another source filter from Damian that provides a switch... case sort of syntax, together with HTML::Mason and mod_perl. It led to some really strange errors that didn't really make sense, but the errors went away when I stopped using Switch. Wes Perrin Harkins [EMAIL PROTECTED] on 05/29/2003 05:56:05 PM To:[EMAIL PROTECTED] cc:John Saylor [EMAIL PROTECTED], modperl [EMAIL PROTECTED] Subject:RE: how to secure perl modules? On Thu, 2003-05-29 at 17:41, Kirk Rogers wrote: why the scarcasm? You asked a very loaded question that is guaranteed to get you a lot angry responses on most Perl mailing lists. Hiding your source code is a FAQ ( http://perldoc.com/perl5.8.0/pod/perlfaq3.html#How-can-I-hide-the-source-for-my-Perl-program- ) so the real question is more whether or not the method you've chosen to hide it works with mod_perl. I believe source filters do work, although I've never tried them myself. If you search in the mail archives you'll find many long and flaming threads on the subject. Personally, I would appreciate it if everyone would let this thread die quietly unless they have something specific to add about the use of source filters (or alternate methods) with mod_perl. If you want to argue the ethics of hiding source code, please do it off the list. - Perrin
