running 2 versions of apache and mod perl on the same machine
We are moving to a new web server and we have installed apache 2.0.48 with mod_perl 1.99_12. We are running perl 5.8.1 on a Sun Solaris machine. One of the applications that we run on our web server is an eprints server which is system for archiving documents. When one compiles eprints, one essentially compiles it together with apache and mod perl. As a matter of fact on our present server, we have 2 apache processes running - the standard one on port 80, and the apache process with eprints on port 81. The problem is that we are having problems compiling eprints on our new server using apache 2 and mod perl 2 and I was wondering if we could compile eprints with apache 1.3 and mod perl 1. In other words, is it possible to run 2 apache processes on the same machine, one with apache 2 and mod perl 2, and one with apache 1.3 and mod perl 1. Any help will be appreciated. Malki Cymbalista Webmaster, Weizmann Institute of Science Rehovot, Israel 76100 Internet: [EMAIL PROTECTED] 08-934-3036 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: running 2 versions of apache and mod perl on the same machine
Hi!
On Wed, Jan 07, 2004 at 09:27:49AM +0200, Malka Cymbalista wrote:
1. In other words, is it possible to run 2 apache processes on the same
machine, one with apache 2 and mod perl 2, and one with apache 1.3 and
mod perl 1.
I know nothing about eprints, but it should be no problem to have different
versions of Apache/mod_perl ruinning on the same machine, as long as you use
different ports for each one.
Eg, on my devbox, I've got two mod_perl 1 servers (one on port 80, on on
port 8080) and one Apache 2/Subversion server (running on port 1000)
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Different results using mod_proxy or mod_rewrite vs direct server
I'm setting up a HTTP/HTPPS reverse proxy server with apache on my DMZ. The proxy will access an internal server (insidelan.server.com) to provide content to outside users. I've attempted using mod_proxy: VirtualHost 1.2.3.4:80 ServerName insidelan.server.com ProxyPass / http://insidelan.server.com/ ProxyPassReverse / http://insidelan.server.com/ /Virtualhost and using mod_rewrite: VirtualHost 1.2.3.4.90 ServerName insidelan.server.com RewriteRule /(.*)$ http://insidelan.server.com/$1 [P] /VirtualHost Everything seems to work fine (including the HTTPS proxy, cookies, etc., etc.), except that I'm getting: Proxy Error The proxy server received an invalid response from an upstream server The proxy server could not handle the requet GET /perl/program.pl Reason: Document contains no data The very same URL: http://insidelan.server.com/perl/program.pl (that runs under Apache::Registry) works just fine when used from inside the LAN (that is, directly). I also copied program.pl to the cgi-bin directory (to run it as a standard CGI), and called the resulting URL: http://insidelan.server.com/cgi-bin/program.pl and what comes up is the text of the generated HTML page. Strangely enough, some other perl scripts (in cgi-bin or perl) work fine through the proxy. The proxy is Apache 1.3.29, mod_perl 1.27. The server inside the LAN is: Apache 1.3.26,mod_perl 1.27 I'm crossposting because the problem seems to be originated in the combination perl/reverse proxy. Any help will be appreciated. Rafael -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
mod_perl + PHP not logging $r-user
I'm using Apache 2.0.48, mod_perl 1.99_12, and Apache::AuthCookie to create a custom authentication scheme. I've noticed that while apache normally logs the $REMOTE_USER, it doesn't log it when accessing PHP pages. The pages are still correctly protected. At first I thought $_SERVER[REMOTE_USER] wasn't always being populated by PHP, but it looks like that is working. However, $PHP_AUTH_USER isn't getting set. I suspect that Apache logging and $PHP_AUTH_USER are related issues. At work, we currently use a proprietary Apache 2 authentication module that successfully logs the user and populates $PHP_AUTH_USER, so I know it can be done. Would it be possible to modify mod_perl and/or Apache::AuthCookie to do the same? I've done alot of googling, but I haven't been able to find mention of my problem. Is this an known issue? If so, what is the solution? I've only been using mod_perl about a week, but I'm loving it so far. Amazing stuff. -- Stuart Jansen [EMAIL PROTECTED], AIM:StuartMJansen The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. -- Fredrick Brooks, Mythical Man Month signature.asc Description: This is a digitally signed message part
Re: [mp1] signal handler for USR2 in startup.pl doesn't work
this is working for me. thanks for the suggestion!
use POSIX;
my $sigset = POSIX::SigSet-new();
my $action = ""> 'sigUSR2_handler', $sigset, POSIX::SA_NODEFER,);
POSIX::sigaction(POSIX::SIGUSR2, $action);
sub sigUSR2_handler { warn "got SIGUSR2\n";}
Re: [mp1] modules not shared across children. preloading or fork()issue?
Problem solved. Turned out to be some kernel patches redhat has applyed to their kernel. It works fine with a vanilla kernel, litteraly all memory is reported as being shared between apache processes now like it was before. Thanks for your help. Danni - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: Daniel Wilson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 9:54 PM Subject: Re: [mp1] modules not shared across children. preloading or fork()issue? On Mon, 2004-01-05 at 00:36, Daniel Wilson wrote: This happened after moving to a new server running the same redhat 9 but with different kernels and glibc's. Are you absolutely positive that nothing else changed? Not the Perl build, not the apache build, not your code, not your config files? 1. mod_perl is not loading modules before the fork()'s. Easy to verify. Dump %INC at the end of your startup.pl and it will show you what has been loaded. --- httpd.conf # PerlModule Apache::Registry Apache::RegistryLoader DBD::mysql BSD::Resource DBI PerlModule Storable Text::Kakasi Encode::Encoding Apache::DBI Carp PerlModule IPC::Shareable Jcode IPC::SysV Encode Encode::Alias Lingua::JA::Romaji There used to be a limit on how many modules you could load with PerlModule. I'm not sure if there still is. Try moving all of these into startup.pl instead. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + PHP not logging $r-user
Stuart Jansen wrote: I'm using Apache 2.0.48, mod_perl 1.99_12, and Apache::AuthCookie to create a custom authentication scheme. I've noticed that while apache normally logs the $REMOTE_USER, it doesn't log it when accessing PHP pages. The pages are still correctly protected. the way these environment variables work is that if a module (mod_php, mod_perl, mod_cgi) wants them visible to users they call a few core Apache APIs (ap_add_common_vars and ap_add_cgi_vars) to generate them in the subprocess_env table. it's then further up to the individual module to make the contents of that table visible to the environment. mod_cgi uses another core Apache call, while mod_perl does it manually. I can see the call to ap_add_common_vars() in the php code, which is the core API that populates REMOTE_USER in the environment, provided r-user was previously set (generally by a call to get_basic_auth_pw, which Apache::AuthCookie does). are other variables, such as DOCUMENT_ROOT or SERVER_ADMIN present? if this were mod_perl, you would need to use PerlOptions +SetupEnv in your httpd.conf to make the variables visible. I'm not php savvy - is there an option you're missing someplace? At first I thought $_SERVER[REMOTE_USER] wasn't always being populated by PHP, but it looks like that is working. However, $PHP_AUTH_USER isn't getting set. I suspect that Apache logging and $PHP_AUTH_USER are related issues. At work, we currently use a proprietary Apache 2 authentication module that successfully logs the user and populates $PHP_AUTH_USER, so I know it can be done. Would it be possible to modify mod_perl and/or Apache::AuthCookie to do the same? well, you mean have Apache::AuthCookie populate PHP_AUTH_USER? probably not, since it's rather PHP specific :) I've done alot of googling, but I haven't been able to find mention of my problem. Is this an known issue? If so, what is the solution? I've only been using mod_perl about a week, but I'm loving it so far. Amazing stuff. indeed. you've reached the point of no return now. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp2) mp1.99_12 fails 9/18 in apache_file.t
from .tgz on 2.0.48 from src on RH7.3: -8-- Start Bug Report 8-- 1. Problem Description: mod_perl 1.99_12 fails test, yada yada, see subject line 2. Used Components and their Configuration: *** mod_perl version 1.9912 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS= /appl/apache/httpd/prefork/bin/apxs MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /appl/apache/httpd/prefork/bin/httpd -V Server version: Apache/2.0.48 Server built: Nov 21 2003 00:01:11 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -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=/appl/apache/httpd/prefork -D SUEXEC_BIN=/appl/apache/httpd/prefork/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.17-0.13smp, archname=i386-linux uname='linux daffy.perf.redhat.com 2.4.17-0.13smp #1 smp fri feb 1 10:30:48 est 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-109)', 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=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a 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: Built under linux Compiled at Apr 1 2002 12:23:22 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl . *** Packages of interest status: Apache::Request: - CGI: 3.00 LWP: 5.76 mod_perl : 1.9911 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Thu Jan 8 03:47:42 2004 GMT. 4. This is the make error: Failed 9/18 tests, 50.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- compat/apache_file.t 189 50.00% 10-18 5. This is the verbose error_log for the failing file: END in modperl_extra.pl, pid=18828 [Wed Jan 07 22:44:58 2004] [notice] Apache/2.0.48 (Unix) mod_perl/1.99_12 Perl/v5.6.1 configured -- resuming normal operations [Wed Jan 07 22:44:58 2004] [info] Server built: Nov 21 2003 00:01:11 [Wed Jan 07 22:44:58 2004] [debug] prefork.c(1037): AcceptMutex: sysvsem (default: sysvsem) [Wed Jan 07 22:45:00 2004] [error] [client 127.0.0.1] print() on closed filehandle Symbol::GEN4 at /usr/src/other/mod_perl-1.99_12/t/response/TestCompat/apache_file.pm line 75. [Wed Jan 07 22:45:00 2004] [error] server reached MaxClients setting, consider raising the MaxClients setting [Wed Jan 07 22:45:00 2004] [info] Child process pid=18831 is exiting [Wed Jan 07 22:45:00 2004] [info] Child process pid=18834
Re: [mp1] modules not shared across children. preloading or fork()issue?
Daniel Wilson wrote: Problem solved. Turned out to be some kernel patches redhat has applyed to their kernel. It works fine with a vanilla kernel, litteraly all memory is reported as being shared between apache processes now like it was before. Great. May be you could do a great service to your fellow RH/mp users and report this problem to those in charge at RH... __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
