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 , 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. -- /||** 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=9860080401&w=2&r=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-cvs&m=98873811010574&w=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-cvs&r=1&w=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-modperl&r=1&w=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, GY>sorry for the OT, but has anyone figured out how to tell whether a browser GY>supports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, GY>when entering a 128 bit page, get the standard Cannot Find Server error page GY>with little in the way directions to help the EU know to upgrade. GY> GY>has 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 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 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 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 space 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, > >GY>sorry for the OT, but has anyone figured out how to tell whether a browser >GY>supports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, >GY>when entering a 128 bit page, get the standard Cannot Find Server error >page >GY>with little in the way directions to help the EU know to upgrade. >GY> >GY>has 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/
really odd XML + CGI.pm + mod_perl + Macintosh + IE 4.5 problem
OK I have ben RTFMing for about 5 hours now and I did find a fix for part of my problem It seems that Mac browsers (IE 4.5 and an old AOL that I know of) are having trouble viewing our HTML producing CGI scripts that use a function called &CGI::start_html() Apparently (recently in CGI.pm) there has been a change where the CGI::start_html includes the following This tag is reaking havoc on some browsers on Mac and possibly others. Well after pouring through the "perldoc CGI" I found that if you use CGI(:all -no_xhtml); then you will not get the compile(qw(:all -no_xhtml));#used to optimize CGI.pm memory consumption for forked processes and I have this in the 2 scripts that I actually use in mod_perl use CGI qw(:all -no_xhtml); my problem is that in mod_perl... it still occasionally prints the
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 ) 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, >> >>GY>sorry for the OT, but has anyone figured out how to tell whether a browser >>GY>supports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, >>GY>when entering a 128 bit page, get the standard Cannot Find Server error >>page >>GY>with little in the way directions to help the EU know to upgrade. >>GY> >>GY>has 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
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:
UseCanonicalName Off
if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
{
$VirtualDocumentRoot = "/www/httpd/html/$1";
}
else
{
$VirtualDocumentRoot = '/www/httpd/html/%-3';
}
1;
The second $VirtualDocumentRoot line works fine, but I NEED to be able to
get the first line to work instead, using if possible.
Any guesses?
Jonathan
Re: 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: 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:
>
>
> UseCanonicalName Off
>
>
> if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
> {
> $VirtualDocumentRoot = "/www/httpd/html/$1";
> }
> else
> {
> $VirtualDocumentRoot = '/www/httpd/html/%-3';
> }
>
> 1;
>
>
>
>
>
> The second $VirtualDocumentRoot line works fine, but I NEED to be able to
> get the first line to work instead, using 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 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 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 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/
Re: [OT] 128 bit encryption and IE
On Mon, May 07, 2001 at 11:39:59AM -0400, Geoffrey Young 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. If you set your site to accept only 128 bit ciphers, this is what will happen because the browsers that are capable of upgrading from 56 to 128 bit encryption do this by first connecting at 56 and the renegotiating at 128. See also http://www.modssl.org/source/exp/mod_ssl/pkg.mod_ssl/README.GlobalID > > has anyone battled this and come up with an elegant solution? > It would of course help a bit if you told us which server you're trying to do this on ;-) With Apache+mod_ssl it is quite simple - just configure it to allow the weak ciphers, and then limit actual access by using SSLRequire to allow only >= 128 bits encryption. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
