Trying to trace a spinning httpd
Apache 1.3.19/Mod-perl 1.25 under Linux 2.2.19
Hi, I am trying to better understand Apache/mod-perl behaviour under
this scenario. I have some CGI's which connect to various servers
listening on different ports and collect the output and push them to
the clients. Whilst the data is streaming from the server to the CGI,
I kill the server. After a few seconds, I see httpd take up increasing
amount of CPU time [it can go up to 90% of CPU]. straceing the httpd
process shows that it is continuously in a read call to the file
descriptor representing the connection it was last in
I ran httpd in single instance mode [httpd -X] and attached gdb to
it. I sourced .gdbinit and typed curinfo
This is what I get
(gdb) curinfo
Attempt to extract a component of a value that is not a structure
pointer.
A backtrace shows this
(gdb) bt
#0 0x4015eab4 in __libc_read () from /lib/libc.so.6
#1 0x401a81cc in ?? () from /lib/libc.so.6
#2 0x4010d931 in _IO_new_file_underflow (fp=0x8e0db18) at fileops.c:385
#3 0x4010f881 in _IO_default_uflow (fp=0x8e0db18) at genops.c:371
#4 0x4010ecec in __uflow (fp=0x8e0db18) at genops.c:328
#5 0x4010c046 in _IO_getc (fp=0x8e0db18) at getc.c:39
#6 0x80ee671 in Perl_sv_gets ()
#7 0x80e763e in Perl_do_readline ()
#8 0x80e574b in Perl_pp_readline ()
#9 0x81149dd in Perl_runops_standard ()
#10 0x80b9a31 in perl_call_sv ()
#11 0x80743eb in perl_call_handler ()
#12 0x8073bcb in perl_run_stacked_handlers ()
#13 0x8071f9d in perl_handler ()
#14 0x808eb03 in ap_invoke_handler ()
#15 0x80a2639 in process_request_internal ()
#16 0x80a269c in ap_process_request ()
#17 0x8099c7e in child_main ()
#18 0x8099e0c in make_child ()
#19 0x8099f69 in startup_children ()
#20 0x809a5a6 in standalone_main ()
#21 0x809ad33 in main ()
#22 0x400d09cb in __libc_start_main (main=0x809a9ec main, argc=2,
Having the following code and sending a SIGUSR2 also did not help
use Carp ();
$SIG{'USR2'} = sub {
Carp::confess(caught SIGUSR2!);
};
I am looking for ideas to determine where in the perl code could I be
spinning and is there a way for me to tell Apache to recognise that
the other end has shutdown
Regards, Yusuf
--
Yusuf Goolamabbas
[EMAIL PROTECTED]
Re: PHP4 causes DBI connections to fail silently in mod_perl
On Sun, 6 May 2001, Rodney Broom wrote: Hi all, The other day I installed PHP4 as a DSO. No problem, it works fine. Today I was adding a Perl handler that needs a DB connection (MySQL). Nothing special, I used DBI. But at the time of the connection, the handler stops. No error, no message, no anything. - I tried to get a DB handle in an Apache::Registry (mpl) script, same thing. - I tried to get a DB handle from a CGI script, that works. - I turned off PHP in the conf and retried the mpl script, it connects to the DB correctly. I've searched the archives for this list, and done some searching on PHP sites and on the web, but haven't found anything specific. Has anybody else seen this? I may be wrong, but isn't this the issue where you have to compile PHP4 *without* the MySQL libraries. MySQL still works from PHP4, provided you have the MySQL libs on your machine somewhere else. I think there's an FAQ about this on the PHP4 site. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: PHP4 causes DBI connections to fail silently in mod_perl
On Sun, 6 May 2001, Matt Sergeant wrote: Hi everyone, On Sun, 6 May 2001, Rodney Broom wrote: Hi all, I may be wrong, but isn't this the issue where you have to compile PHP4 *without* the MySQL libraries. MySQL still works from PHP4, provided you have the MySQL libs on your machine somewhere else. I think there's an FAQ about this on the PHP4 site. AFAIK: there is a warning in the configure-script of php4 as well. It tells you to use your local mysql-includes when using other modules, like mod_perl... Greetings, Remco Schaar
Re: install perl-win32-bin-0.6.exe on win98
I'm using perl-win32-bin-0.6.exe package, so I use the Perl and Apache binaries that come with it. When everything is unpacked I move the perl subdirectory to c:\Prel, the apache subdirectory to c:\apache and the openssl directory to c:\openssl. When everything is done as it's explained on the installation readme (I think so, but I'm not 100% sure),I try to execute apache as: Apache.exe -f conf\httpd.conf-perl and the error cannot load /apache/modules/apachemoduleperl into server appears.
RE: Apache::Filter upgrade issues...
-Original Message-
From: Trevor Phillips [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 05, 2001 2:21 AM
To: ModPerl Mail List
Subject: Apache::Filter upgrade issues...
Hi! I recently upgraded a test server to a recent
Apache::Filter, and hit
problems due to the new dependency on filter_register() being
called. I
don't mind upgrading my filters to call this, but I have one,
in which I
use Apache::Request (a sub-class of Apache), which I cannot
seem to work
around.
The guts of the code goes something like this:
sub handler
{
my $r = shift;
my $IsFilter = ($r-dir_config('Filter') =~ /^on/i?1:0);
$r = Apache::Request-new($r);
if ($IsFilter)
{
$r = $r-filter_register();
my ($fh, $status) = $r-filter_input();
return $status unless $status == OK; # The Apache::Constants OK
my @file = $fh;
}
etc...
}
The above code fails in that the extra methods provided by
Apache::Request
are
no longer there.
The above code worked fine previously (prior to the requirement of
filter_register)...
Any ideas? How can I use both Apache::Filter and
Apache::Request together?
well, part of the problem is that Apache-request($r) doesn't bless a new
request properly.
I know that Ken has recently tried working on the problem and had placed it
on Doug's radar:
http://marc.theaimsgroup.com/?t=9860080401w=2r=1
(ping :)
at any rate, it probably won't work, but maybe try switching the order
around? That is, maybe call Apache::Request-new on the request object
returned by filter_register?
HTH
--Geoff
[DIGEST] mod_perl digest 04/29/01
-- mod_perl digest April 29, 2001 - May 5, 2001 -- Recent happenings in the mod_perl world... Features o mod_perl status o cvs patches o mailing list highlights o links mod_perl status o mod_perl - stable: 1.25 (released January 29, 2001) [1] - development: 1.25_01-dev [2] o Apache - stable: 1.3.19 (released February 28, 2001) [3] - development: 1.3.20-dev [4] o Perl - stable: 5.6.1 (released April 9, 2001) [5] - development: 5.7.1 [6] cvs patches o added $r-allowed method [7] mailing list highlights o A good discussion of exception handling appeared on the list this week, ranging from Perl's eval() syntax to Error.pm to Java-like exception handling [8] o The discussion again surfaced about whether you can use mod_perl to alter the Server response header. The short answer is that you can't without changing the Apache source code or writing your own version of send_http_header. That is, unless you use XS, but Matt isn't sharing until the next release of AxKit :) [9] o The official call for papers for ApacheCon Europe was announced this week [10] o 66 patches to 2.0 this week... [11] links o The Apache/Perl Integration Project [12] o mod_perl documentation [13] o mod_perl modules on CPAN [14] o mod_perl homepage [15] o mod_perl news and advocacy [16] o mod_perl list archives [17] [18] happy mod_perling... --Geoff [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.cpan.org/src/stable.tar.gz [6] http://www.cpan.org/src/devel.tar.gz [7] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=98873811010574w=2 [8] http://forum.swarthmore.edu/epigone/modperl/lermranpha [9] http://forum.swarthmore.edu/epigone/modperl/chulphermway [10] http://forum.swarthmore.edu/epigone/modperl/khendwhondwend [11] http://marc.theaimsgroup.com/?l=apache-modperl-cvsr=1w=2 [12] http://perl.apache.org [13] http://perl.apache.org/#docs [14] http://www.cpan.org/modules/by-module/Apache/ [15] http://www.modperl.com [16] http://www.take23.org [17] http://forum.swarthmore.edu/epigone/modperl/ [18] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
RE: Apache::Filter upgrade issues...
I've run into this before as well, and what i ended up doing to get around
it was keeping the original $r around long enough to call filter_register.
my $r = shift;
my $req = Apache::Request-new($r);
$r = $r-filter_register();
adam
-Original Message-
From: Trevor Phillips [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 05, 2001 2:21 AM
To: ModPerl Mail List
Subject: Apache::Filter upgrade issues...
Hi! I recently upgraded a test server to a recent
Apache::Filter, and hit
problems due to the new dependency on filter_register() being
called. I
don't mind upgrading my filters to call this, but I have one,
in which I
use Apache::Request (a sub-class of Apache), which I cannot
seem to work
around.
The guts of the code goes something like this:
sub handler
{
my $r = shift;
my $IsFilter = ($r-dir_config('Filter') =~ /^on/i?1:0);
$r = Apache::Request-new($r);
if ($IsFilter)
{
$r = $r-filter_register();
my ($fh, $status) = $r-filter_input();
return $status unless $status == OK; # The Apache::Constants OK
my @file = $fh;
}
etc...
}
The above code fails in that the extra methods provided by
Apache::Request
are
no longer there.
The above code worked fine previously (prior to the requirement of
filter_register)...
Any ideas? How can I use both Apache::Filter and
Apache::Request together?
--
. Trevor Phillips -
http://jurai.murdoch.edu.au/ .
: CWIS Systems Administrator - [EMAIL PROTECTED] :
| IT Services - Murdoch University |
--- Member of the #SAS# #CFC#
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
[OT] 128 bit encryption and IE
Hi all... sorry for the OT, but has anyone figured out how to tell whether a browser supports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, when entering a 128 bit page, get the standard Cannot Find Server error page with little in the way directions to help the EU know to upgrade. has anyone battled this and come up with an elegant solution? thanks --Geoff
Re: [OT] 128 bit encryption and IE
Hello, GYsorry for the OT, but has anyone figured out how to tell whether a browser GYsupports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, GYwhen entering a 128 bit page, get the standard Cannot Find Server error page GYwith little in the way directions to help the EU know to upgrade. GY GYhas anyone battled this and come up with an elegant solution? Mainly, this just sucks. One possibility is that on any page the user is supposed to hit BEFORE going SSL, to have a warning if the browser sniffs to be a recent IE. I would just add the warning for any IE browser. It's harder if your entire site is SSL. I'm hoping someone will answer with a better solution than dumbing down encryption altogether. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Reading the environment in perl block
Hello. I'm trying to isolate the developper environment from each other so that when someone mess up the server, the others just simply don't know that something happened. So, every developpers will have their own webserver. Since I want to be able to have potentially different copies of Perl modules (like, say, two developpers are working on things that are in the same modules), I can't simply load different virtual host for each developpers : they have their own copy of Apache+mod_perl. The way I've setup whole thing is like that : a script name restart is called with some parameters telling him to reload one or all the developpers environment, or the testing copy. This script would have some environments variables called SITE_USER and SITE_USER_PORT that will give me the value (read in a file defining the different users) of the username (and by the same way the files path) and the port where the user should work. My problem is that my envirnoment variables are not set. If I do a Dumper(\%ENV), I only got values for the variables TZ, GATEWAY_INTERFACE, MOD_PERL and PATH. (I do double-check that my variables where well setup). I've read in the Eagle book that the environment is cleaned up on server start, but I tought that I could read it in raw form in the perl configuration... The only way I still see to make it work is having my restart script saving the current user/port in a file and letting the perl section read it's configuration from there. But it look so patchy... Is there another way to do this? Thanks for any advice Benoit Caron Analyste-Programmeur Netgraphe - Webfin.com - Le Web Financier [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - The number of Unix installations has grown to 10, with more expected. -- The Unix Programmer's Manual, 2nd edition, June '72
RE: Reading the environment in perl block
The way I've setup whole thing is like that : a script name restart is called with some parameters telling him to reload one or all the developpers environment, or the testing copy. This script would have some environments variables called SITE_USER and SITE_USER_PORT that will give The PerlPassEnv directive should work for this, shouldn't it? I've experienced that it puts the (explicitly named) environment variables into perlspace pretty effectively. HTH! L8r, Rob
Re: [OT] 128 bit encryption and IE
Another thing you might consider if Verisign will sell them is to get a Global Server certificate. They are designed for banks. It used to be that if you were a financial institution you could get this special server certificate for SSL which would trigger a 'step up' in cripplied netscape and IE to 128 bit encryption. Now, with strong encryption walls having been broken down in the US, maybe global certs no longer qualify you to have to be a bank? At 10:36 AM 5/7/01 -0700, Andrew Ho wrote: Hello, GYsorry for the OT, but has anyone figured out how to tell whether a browser GYsupports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, GYwhen entering a 128 bit page, get the standard Cannot Find Server error page GYwith little in the way directions to help the EU know to upgrade. GY GYhas anyone battled this and come up with an elegant solution? Mainly, this just sucks. One possibility is that on any page the user is supposed to hit BEFORE going SSL, to have a warning if the browser sniffs to be a recent IE. I would just add the warning for any IE browser. It's harder if your entire site is SSL. I'm hoping someone will answer with a better solution than dumbing down encryption altogether. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: [OT] 128 bit encryption and IE
Gunther Birznieks [mailto:[EMAIL PROTECTED]] wrote: Now, with strong encryption walls having been broken down in the US, maybe global certs no longer qualify you to have to be a bank? Thawte calls these SuperCerts and you don't have to be a bank: }} Who can get a SuperCert? }} The new US encryption export regulations took effect on }} 14 January 2000. In terms of the new regulations, Thawte }} may now export SuperCerts to any non-government entity }} and to any commercial government-owned entity (except }} those that produce munitions), in any country except }} Afghanistan (Taliban-controlled areas), Cuba, Iran, Iraq, }} Libya, North Korea, Serbia (except Kosovo), Sudan and }} Syria. See: http://www.thawte.com/certs/server/128bit/contents.html David
Re: 128 bit encryption and IE
Thawte (or verisign-lite grin) sells them also, they are called (IIRC) SGC - Server Gated Crypto keys. I use them for our private corporate extranet web servers. My company is certainly not a financial institution, but in the healthcare industry. Be aware, they only work for newer versions of the crippled browser, very old versions of Netscape and IE will __not__ step up, so to speak. Thawte has a very good explanation of this on their web site. http://www.thawte.com/certs/server/128bit/contents.html Brgds, Mike. On Monday, May 07, 2001, Gunther Birznieks wrote the following about [OT] 128 bit encryption and IE GB Another thing you might consider if Verisign will sell them is to get a GB Global Server certificate. They are designed for banks. It used to be that GB if you were a financial institution you could get this special server GB certificate for SSL which would trigger a 'step up' in cripplied netscape GB and IE to 128 bit encryption. GB Now, with strong encryption walls having been broken down in the US, maybe GB global certs no longer qualify you to have to be a bank? GB At 10:36 AM 5/7/01 -0700, Andrew Ho wrote: Hello, GYsorry for the OT, but has anyone figured out how to tell whether a browser GYsupports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, GYwhen entering a 128 bit page, get the standard Cannot Find Server error page GYwith little in the way directions to help the EU know to upgrade. GY GYhas anyone battled this and come up with an elegant solution? Mainly, this just sucks. One possibility is that on any page the user is supposed to hit BEFORE going SSL, to have a warning if the browser sniffs to be a recent IE. I would just add the warning for any IE browser. It's harder if your entire site is SSL. I'm hoping someone will answer with a better solution than dumbing down encryption altogether. Best Regards, Mike Miller [EMAIL PROTECTED]
RE: [OT] 128 bit encryption and IE
Geoffrey Young [mailto:[EMAIL PROTECTED]] wrote: Hi all... sorry for the OT, but has anyone figured out how to tell whether a browser supports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, when entering a 128 bit page, get the standard Cannot Find Server error page with little in the way directions to help the EU know to upgrade. has anyone battled this and come up with an elegant solution? thanks --Geoff If you are getting a Cannot Find Server error in 56-bit browsers it is because the server and browser are not able to negotiate a cipher to use. Normally, the SSL server will simply downgrade the key size and talk appropriately with 56 bit browsers. However, in configuring your SSL server you can limit what ciphers and key sizes will be considered acceptable. Consider allowing your server to use non 128-bit ciphers. Under mod_ssl configure the SSLCipherSuite configuration directive appropriately. (Also look at the SSLRequire directive if this does not solve things.) Docs here: http://www.modssl.org/docs/2.8/ssl_reference.html#ToC9 To determine the cipher currently being used, look at the environment under mod_ssl. My server shows me this for a sample connection: SSL_CIPHER=RC4-MD5 SSL_CIPHER_ALGKEYSIZE=128 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=128 Docs here: http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25 I'm sure you can build whatever system you need on top of this. David
Perl Sections in Apache Config
Hi,
I've been trying to do this for some time but can't figure out how.
Basically I want a setup where anyone at www.UserName.domain.com or
UserName.domain.com will have their DocumentRoot set to
/www/httpd/html/UserName. So far I've tried this:
VirtualHost 111.111.111.111
UseCanonicalName Off
Perl
if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
{
$VirtualDocumentRoot = /www/httpd/html/$1;
}
else
{
$VirtualDocumentRoot = '/www/httpd/html/%-3';
}
1;
/Perl
/VirtualHost
The second $VirtualDocumentRoot line works fine, but I NEED to be able to
get the first line to work instead, using Perl if possible.
Any guesses?
Jonathan
Re: Perl Sections in Apache Config
I'm running into a similiar issue, and I from what I've read,
mod_vhost_alias looks like it could help:
http://httpd.apache.org/docs/mod/mod_vhost_alias.html
Any comments on this mod?
Brian B.
- Original Message -
From: Jonathan Hilgeman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 8:35 PM
Subject: Perl Sections in Apache Config
Hi,
I've been trying to do this for some time but can't figure out how.
Basically I want a setup where anyone at www.UserName.domain.com or
UserName.domain.com will have their DocumentRoot set to
/www/httpd/html/UserName. So far I've tried this:
VirtualHost 111.111.111.111
UseCanonicalName Off
Perl
if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
{
$VirtualDocumentRoot = /www/httpd/html/$1;
}
else
{
$VirtualDocumentRoot = '/www/httpd/html/%-3';
}
1;
/Perl
/VirtualHost
The second $VirtualDocumentRoot line works fine, but I NEED to be able to
get the first line to work instead, using Perl if possible.
Any guesses?
Jonathan
Re: really odd XML + CGI.pm + mod_perl + Macintosh + IE 4.5 problem
Well after pouring through the perldoc CGI I found that if you
use CGI(:all -no_xhtml);
then you will not get the ?xml- tag that is fragging the browsers...
unfortunately in mod_perl, It only seems to work on *some*
of the children
We had the same problem with -oldstyle_urls.
Below is what I did because I didn't know better. Enlightenment welcome.
from startup.pl (you would use $XHTML):
use CGI qw(-compile -oldstyle_urls :all);
#
# override CGI::initialize_globals to avoid the default for
# $CGI::USE_PARAM_SEMICOLONS (we always use -oldstyle_urls)
#
# Caution:
# This works as long as NO script explicitly uses -newstyle_urls.
#
# Background:
# CGI.pm registers an Apache cleanup handler to call reset_globals,
# which in turn uses initialize_globals. Since _setup_symbols
# (which handles the -oldstyle_urls option) runs only once
# for every httpd-instance under mod_perl this option works
# only for the first ~MaxServers invocations of the script.
#
my $real_initialize_globals = \CGI::initialize_globals;
undef *CGI::initialize_globals;
*CGI::initialize_globals = sub {
$real_initialize_globals();
$CGI::USE_PARAM_SEMICOLONS = 0;
};
Regards, Bjoern
--
Bjoern Kriews - mobile.de GmbH - Softwareentwicklung
Bueschstr. 7 - D-20354 Hamburg
Tel.: +49 (0) 40 / 879 77-406; Fax: +49 (0) 40/43 18 23-55
Web: http://www.mobile.de
Re: Reading the environment in perl block
On Mon, 7 May 2001, Benoit Caron wrote: The way I've setup whole thing is like that : a script name restart is called with some parameters telling him to reload one or all the developpers environment, or the testing copy. This script would have some environments variables called SITE_USER and SITE_USER_PORT that will give me the value (read in a file defining the different users) of the username (and by the same way the files path) and the port where the user should work. My problem is that my envirnoment variables are not set. If I do a Dumper(\%ENV), I only got values for the variables TZ, GATEWAY_INTERFACE, MOD_PERL and PATH. (I do double-check that my variables where well setup). You could try PerlPassEnv: PerlPassEnv SITE_USER PerlPassEnv SITE_USER_PORT ...but the solution I've used is to have the startup script dynamically build a configuration based on a configuration template. In fact, the script doesn't even live in /etc anywhere -- it's part of the CVS checked out area that each developer has individually. The config template is just a standard Apache config file with special @@ tokens in it like the Apache *.orig files: ServerRoot @@SERVERROOT@@ Port @@SERVERPORT@@ The script changes these tokens when (re)starting Apache, and runs apache -f /tmp/httpd-[user]-[port].conf. It also takes things a step further in that it automatically calculates a port number based on the value of the server root, by running it through sum. This way, you don't need to decide on a port for everybody -- they just check out a copy of the website and start it. If they want to have another copy of the website, let's say under ~/website-hacking, that's fine -- it'll decide on a different port automatically. I can send the startup script and config template if you want to see what I mean. The only way I still see to make it work is having my restart script saving the current user/port in a file and letting the perl section read it's configuration from there. But it look so patchy... Eyuuc
vhost and mod_perl
I use vhost_alias_module to set up subdomains for different users. -- at my httpd.conf VirtualDocumentRoot /home/%-4/web And use Apache::Registry to run the *.cgi script. I got problem with the following situation Script 1: /home/user1/web/index.cgi Address: http://user1.level3.level2.com Script 2: /home/user2/web/index.cgi Address: http://user2.level3.level2.com Sometimes the scripts got mixed up. When accessing http://user1.level3.level2.com, the server gives me the script /home/user2/web/index.cgi instead. Was my setting a problem? How can I have the script print out the package's name in which it is running? Thanks, Bird.
Re: vhost and mod_perl
check out this section in the guide: http://thingy.kcilink.com/modperlguide/config/A_Script_From_One_Virtual_Host_C.html Bird Lei wrote: I use vhost_alias_module to set up subdomains for different users. -- at my httpd.conf VirtualDocumentRoot /home/%-4/web And use Apache::Registry to run the *.cgi script. Script 1: /home/user1/web/index.cgi Script 2: /home/user2/web/index.cgi Sometimes the scripts got mixed up. When accessing http://user1.level3.level2.com, the server gives me the script /home/user2/web/index.cgi instead. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
