Apache::Status for 2.0 ?
Please bear with me -- I have recently picked up Apache2 and now trying out mod_perl2 I see Apache::Status listed under the mod_perl2 docs - http://perl.apache.org/docs/2.0/api/Apache/Status.html But I only see mod_perl 1.27 on the CPAN site; Is there another place to obtain a mod_perl2 type module? ( I did search the archives as best I was able - but I only see postings about Apache::Status since 1999... ) I am not real sure I want to install mod_perl1 over my mod_perl2 Apache2 server code... ???/Sx ?
Re: Apache::Status for 2.0 ?
On Monday, June 2, 2003, at 08:29 PM, Stas Bekman wrote: WC -Sx- Jones wrote: I see Apache::Status listed under the mod_perl2 docs - http://perl.apache.org/docs/2.0/api/Apache/Status.html mod_perl-1.99_09 is not indexed by PAUSE, hence you can't see it. (because of _09). If you have installed it, you already have it. It's part of the distro. You mean Apache::Status is in the mod_perl-1.99_09 build I downloaded ? ???/Sx ?
Re: Apache::Status for 2.0 ?
On Monday, June 2, 2003, at 09:19 PM, Stas Bekman wrote: Have you looked? http://perl.apache.org/dist/mod_perl-2.0-current/lib/Apache/Status.pm Yes, of course. :) My question: Was it not installed when I built mod_perl2 ? So, on my server I looked for Apache -- [ results edited to remove ../docs and $HOME matches ] # find / -name Apache -print ... /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/ auto/Apache /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/ Apache ... Then I looked for Status - # find / -name Status -print ( nothing is returned... ) Therefore it was not built when I installed mod_perl 2. -Sx-
Re: Apache::Status for 2.0 ?
On Monday, June 2, 2003, at 09:19 PM, Stas Bekman wrote: http://perl.apache.org/download/index.html Shouldn't there be a warning about mod_perl2 and CPAN then? CPAN definitely wants to download and install mod_perl1 -- even over a valid mod_perl2 installation... Regarding the following off the Other Modules link on the download page: There are several other Perl modules that you might wish to have installed, to take full advantage of mod_perl functionality. Provided you have Andreas König's CPAN.pm module, simply run: cpan install Bundle::Apache This will fetch and install mod_perl and related packages for you all at once. Otherwise, once you've installed mod_perl see the listing by running % perldoc Bundle::Apache I mean I have already built and used mod_perl2 now for a week -- can I cast a vote to have CPAN updated? -Sx- :)
Re: Apache::Status for 2.0 ?
Ignore me - On Monday, June 2, 2003, at 09:37 PM, WC -Sx- Jones wrote: Yes, of course. :) My question: Was it not installed when I built mod_perl2 ? I found (something) at /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/ Apache/Status.pm Now all I have to do is figure out why it doesn't seem to want to work... Sorry/Sx
Re: User process ownership
In-Reply-To: 015501c25393$c8bd6af0$[EMAIL PROTECTED] With your current understanding of Perl/Apache - you cannot do this; however EXPECT (written by Don Libes at expect.nist.gov) can do it -- if you are willing to get a better grip on security issues. Once you see how the expect language works you will see a better way to get Perl/Apache to do it as well :) I know it is not likely the answer you want, but it is a valid path of research AND it will work as it is what I was doing years ago when I ran into similar security issues... Cheers; -Sx- :] On Tuesday, September 3, 2002, at 05:49 PM, John Stauffacher wrote: rights to). The users *ARE* being authenticated via LDAP -- is there any
Re: Seg Fault with PHP and Perl together
# mod_perl - perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1 \ USE_DSO=1 # PHP - ./configure --with-apxs=/usr/local/apache/bin/apxs \ --enable-force-cgi-redirect \ --enable-discard-path \ --with-pear \ --enable-safe-mode \ --with-openssl \ --enable-bcmath \ --with-bz2 \ --with-gdbm \ --with-ndbm \ --enable-dio \ --enable-ftp \ --with-ldap \ --with-mysql=/usr/local/ \ --with-pgsql \ --enable-memory-limit ???/Sx ?
Re: How to limit the size of requests ?
[follow-ups set] PMFJI: Buffer overflow in this case happened because of sub-requests - which are hard to deal with at any rate. The actual GET/POST had nothing to do with the insecure action as far as this issue is concerned, the side effect was caused by the way the sub-request handled the execution/hand-off, so the hack was approximately 50 bytes in size (BTW, I have the BSD C source code for the hack if you want it.) And yes, not to toot any horns, but 'them Apache Groupies' are pretty sharp ! ;) HTH/Sx :] (just another ApacheCon 2000 Orlando Speaker :) On Friday, August 30, 2002, at 02:33 PM, HalbaSus wrote: than packetstorm and securityfocus ? Buffer owerflow under 500 characters ???
Re: mod_perl with a perl built with -Dusethreads, will it work?
On Tuesday 23 July 2002 12:09 pm, regarding mod_perl with a perl built with -Dusethreads, will it work?, Brian wrote: Brian I would like to install Sendmail::Milter which needs a perl built Brian with thread support. Last time I tried to use a perl built with Brian thread support (5.6.x), mod_perl didn't like it. Is this still the Brian case with 5.8.0? Is anybody using mod_perl with a perl built with Brian -Dusethreads? I am using SuSE 7.3 (Linux 2.4.14) Sparc64 with the same perl/apache/et al you mentioned: suse:~/TEST # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.14, archname=sparc64-linux-thread-multi uname='linux suse 2.4.14 #1 mon nov 12 11:25:00 gmt 2001 sparc64 unknown ' config_args='-des -Dcc=gcc -Dprefix=/usr -Dotherlibdirs=/usr/lib/perl5/site_perl/5.6.1 -Dusethreads' 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=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (SuSE)', gccosandvers='' 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 =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lbind -lnsl -lndbm -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lbind -lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jul 23 2002 07:37:37 INC: /usr/lib/perl5/5.8.0/sparc64-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/sparc64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl /usr/lib/perl5/site_perl/5.6.1 . HTH/Sx :]
Re: Static vs. DSO on Linux specifically
Sam Tregar No, the last Redhat Apache/mod_perl I used was in 6.2. I didn't file a Sam Tregar bug about it because after looking around it appeared that it was a well Sam Tregar known problem. After that I started compiling Apache/mod_perl static and Sam Tregar left the seg-faults behind. PMFJI :] Back in RH 6.2 I would hazard that the segfault was more related to Perl being set to uselargefiles and Apache NOT being set. This only became visible when one tried to build mod_perl as a DSO. Building as STATIC caused Apache to be rebuilt using the now current uselargefiles setting. Cheers :) -Sx-
Re: Static vs. DSO on Linux specifically
-Sx- said Building as STATIC caused Apache to be rebuilt using the now current uselargefiles setting. Sam Tregar said I don't think so. Rebuilding Apache/mod_perl static with the exact same Perl that shipped with Redhat 6.2 solved the segfaults. :) How is this different from what I said? :) To better clarify - I said that IF you had tried to build the mod_perl as a DSO and the uselargefiles setting is NOT the same between Perl and Apache (IE - both are either uselargefiles or they are both undef) you WILL get a segfault -- even today. Building as STATIC causes the httpd to be completely rebuilt and the mod_perl settings will cause the Apache binary to match the Perl definition ofd use large files. Building mod_perl as static causes other issues as well - like causing Apache --with-layout to forget which layout it is supposed to use... Oh well; -Sx- :]
