RE: Load balancers
On Mon, 13 Jan 2003, Jesse Erlbaum wrote: That's for all the info so far. To answer some questions, hardware is a cost issue right now. It's somewhat scary that $3,200 was a reasonable price several years ago, but I suppose it could be worse. We will investigate further. Actually, $3200 was a STEAL! Cisco's Local Director was in the mid five-figures at the time, IIRC. :-) No, the local directors were that never that much, maybe low five-figures, like $12-15K or so. Boston.com was running on a pair of (saturated) low end LD's up until around Y2K, when we revamped the load balancing architecture and switched over to ArrowPoint (which then got gobbled up by Cisco) load distributing switches. At that time, a past-its-prime LD could be had for $3K or so, and a state-of-the-art Arrowpoint CS-150 ran around $12K (but we installed the higher capacity CS-800, which ran around $30K each -- just don't ask them to support HTTP 100% correctly... ;^) I've been out of touch with hardware load balancing equipment over the last couple of years, but if the decline in hardware costs of these things has continued, I'd guess a reasonably chunky solution can be had in the $5-7K range at this point. (Of course, you'd need to multiply that cost by two for complete redundancy...) [ Love to hear from someone with current knowledge if this is the case though...] -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: mod_perl via ssl?
You need to specify a command line option of -DSSL when you start the server. If you're using the stock apachectl, it's usually './apachectl start_ssl' Not that this question is on topic... On Tue, 21 May 2002, Chris Garrigues wrote: I've been lurking on this list for a while but hadn't actually been running mod_perl. I'm now trying to get it working on my system, but have hit a wall that I'm sure someone can tell me how to get around. I'm using the Mandrake RPMs for apache and mod_ssl: apache-conf-1.3.23-4mdk apache-1.3.23-4mdk apache-devel-1.3.23-4mdk apache-modules-1.3.23-4mdk apache-mod_perl-1.3.23_1.26-5mdk apache-common-1.3.23-4mdk libopenssl0-0.9.6c-2mdk openssl-0.9.6b-10 mod_ssl-2.8.7-2mdk openssl-devel-0.9.6b-10 I just updated to this version and think I now have my conf files correct in the new architecture although I haven't actually run anything under mod_perl yet. My question is that all my CGIs that I want to convert to mod_perl run under SSL, but I can't figure out how to enable SSL in the httpd-perl server. Am I missing something simple? Chris -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Location header blows away Set-Cookie?
I think this is in the Guide somewhere, but the short answer is to use 'err_header_out()' rather than 'header_out' for any type of non-success result. On Fri, 12 Apr 2002, Thomas K. Burkholder wrote: Apologies if this is well-known - a generalized search failed to explain the behaviour I'm seeing. Using: Apache/1.3.23 (Unix) Debian GNU/Linux mod_ssl/2.8.7 OpenSSL/0.9.6c mod_perl/1.26 I'm using a perl handler in which I create a session and bind it to a cookie if a session doesn't already exist, fetch some results from a database, put the results in the session, then redirect to another page that is responsible for pulling the results out of the session and producing the html output. As a test case, I do exactly this: $r-header_out(Set-Cookie = 'foo1=bar1'); $r-header_out(Location = $redir); return REDIRECT; I use curl to test with - the result does not contain the Set-Cookie header. Is it expected behaviour that redirection should blow away Set-Cookie headers, and I just have to find a different way to do this? I'm pretty sure this isn't a caching issue since I'm using curl to initiate the test. Am I barking up the wrong tree? Thanks in advance for any help- //Thomas Thomas K. Burkholder -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: mod_perl restart vs. graceful
Hi Darren,
See my suggested refinement below (I don't like to leave the server
down any longer than needed...8^):
On Tue, 9 Apr 2002, darren chamberlain wrote:
For exactly this reason, I always modify apachectl so that the restart
option looks like:
restart)
timeout=${2:-5}
count=0
$0 stop
while [ $count -lt $timeout ]; do
while [ -f $PIDFILE -a $count -lt $timeout ]; do
echo -n .
sleep 1
count=`expr $count + 1`
done
echo
$0 start
;;
This will sleep for $2 (or 5 seconds) between stopping and starting.
The sleep ensures that the start doesn't get called too quickly.
Steve
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Authenticating against Active Directory
Does anyone have any experience in writing an authentication handler that authenticates against Microsoft's Active Directory? I have a project for a client who wants to use their existing AD data for user data (username, password, realname, groups, etc). In doing a little googling, it seems that AD is sort of like LDAP, but I couldn't find any definitive info that something like Apache::AuthenLDAP will just work against AD. (The Apache server piece would be Linux, if that matters...) (I saw the recent O'Reilly article on doing AD integration, but that seemed to rely on deploying a proxy process on the AD server, which I'd like to avoid, if possible.) Thanks for any insight anyone can add. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: [OT] Apache Config Problem
Yes, just add a 'Port 80' line to your VirtualHost section. While many folks assume that this directive is for telling apache which port to listen on (it's not -- the Listen directive does that...), it's actually a setting that instructs Apache to use the named port in any generated urls. (At least, that's my understanding of it, and it appears to work like that for me...) UseCanonical tells apache to always use the canonical (ServerName) setting in generated urls -- that allows you to have a ServerAlias for something like 'foo.com', and have generated urls redirect to to 'www.foo.com'. So, if you virtual host was something like: Listen 192.168.0.100:8080 VirtualHost 192.168.0.100:8080 ServerName www.foo.com ServerAlias foo.com Port 80 ... /VirtualHost Then (assuming your bigip sends requests for foo.com to 192.168.0.100:8080) generated urls will be to 'http://www.foo.com:80/' (I think the ':80' is dropped as the default port...) HTH, Steve On Tue, 19 Feb 2002, Robert Landrum wrote: I'm trying to do something really simple and trying to avoid writing an Modperl handler to do it. We have a website behind a bigip running on port 8080. When someone requests a URL that doesn't end with a slash, it's redirected to http://host:8080/path/ . I tried turning off UseCononicalName, but it didn't have any effect. Any suggestions? Thanks, Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Influencing @INC list
OK, I'll be the one to throw out the gratuitous plug for Geoff, etal's book. The Mod_Perl Cookbook has a nice discussion of exactly this in Chapter 2. (I'd give you the page, but I left it at work...) (I'm only through the first few chapters, but from what I've read so far, this is a real winner. Buy it.) Steve On Mon, 11 Feb 2002, Brian Reichert wrote: On Mon, Feb 11, 2002 at 04:29:43PM -0500, Kevin Slean wrote: Mod Perl Mongers... I need to run multiple apache servers on one Solaris 2.7 box configured in such a way that each of them accesses their own private copy of perl libraries. I would like to achieve this configuration with the least amount of changes to my over all implementation. For instance, given 2 apache servers defined in the following 2 directories: /usr/local/siteA - directory tree containing everything for server A /usr/local/siteB - directory tree containing everything for server B The default perl installation on this unix system is under /usr/local/lib/perl5 and the default @INC list is: I believe you can abuse PERL5LIB in each vhost... Kevin -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
[OT] Re: New mod_perl Logo
All right -- I know I should just silently delete this, and let it go, but it's like a bad traffic accident, I just have to sneak a look. In exactly what way do you connote American-style out of any of those names? The fact that Big Foot is a mythical being often associated with the US northwest? (I think the Canadians talk about Big Foot too...) And racist?? Come on, that's certainly a reach... When in doubt, accuse others of being provincial, and act damn indignant. Curse their nationality too... Steve Reppucci On Wed, 30 Jan 2002, Ron Savage wrote: Jeezus you guys. All these American-style names are verging on the racist. This is world-wide code, not f---ing American-wide code. Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Wednesday, January 30, 2002 12:48 PM Subject: Re: New mod_perl Logo In a message dated 30-Jan-02 12:50:50 AM GMT Standard Time, [EMAIL PROTECTED] writes: How about BigFoot? Probably not the best for a server application. Might make one think of the footprint involved ... and isn't one of the major reasons to moving to mod_perl to reduce the overhead and footprint of the server? Now Yetti no conotation there. Or Swamp Beast, Sasquatch, or possibly even the local favorite Nessie (I'd love to see Ora get a picture of her on the next book!) -Chris -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Cgi permission Questions
On Mon, 21 Jan 2002, Joe Bifano wrote: Hi all, My first time on the list. I have been looking at the archives but am not able to find anything on this. Exactly. Because this list is about perl, specifically mod_perl, while your question is about Apache, and its configuration. Please don't ask questions here which have no relevance. There are other lists that discuss these issues. Please visit http://www.apache.org/httpd/, where there is a wealth of great documentation put together through the effort of volunteers to answer exactly this question. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Vhosts + mod_perl
Well, you certainly haven't inconvenience yourself by taking the time to look at the copious documentation available on this, now have you? That said, here's a snippet of what you want to use: NameVirtualHost 192.168.0.10 VirtualHost 192.168.0.10 ServerName www.logsoft.com ServerAlias logsoft.com ServerAlias www2.logsoft.com DocumentRoot /var/apache/htdocs Options +ExecCGI +Indexes AddHandler cgi-script .cgi Location /perl SetHandler perl-script PerlFreshRestart On PerlHandler Foo:Bar PerlSetVar SOME_VAR /usr/local/foo /Location /VirtualHost hth, Steve On Sat, 1 Dec 2001, James wrote: Does anyone have a quick example of setting up a vhost with mod_perl enabled please? Also an ordinary cgi-bin, with file extensions .pl and .cgi enabled? Also with a vhost, I can name the host anything I like can't I? For example, say my domain is localhost.localdomain but I'm using dyndns to make it a hostname, say, trains.ath.cx. I can assign fred.trains.ath.cx and john.trains.ath.cx with vhosts, the requests will get piped to my main machine which is trains, and the vhost section will take care of the rest, knowing which document root to use, right? I don't have to mess around with DNS or anything do I to make new subdomains? Is it: virtualhost fred.trains.ath.cx /doc/root Options +Indexes +ExecCGI DocumentIndex ??? index.html default.html perl-handler # hmm, get mod_perl working in /doc/root/perl cgi-bin # hmmm, get a cgi-bin happening in /doc/root/cgi-bin /virtualhost Or something like that? Many Thanks. James -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: DSO Issues
If we're collecting a list of things that don't work in a DSO build, add perl subs (via !--#perl sub=My::handler--). At least, they didn't work as of January of this year. On Tue, 27 Nov 2001, John Chia wrote: On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP it. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: New user help
Build apache first, then build mod_perl. The mod_perl install modifies the apache tree (it asks you for a path to the apache tree to modify, but defaults to ../apachelatest version) If you're new to mod_perl, you'll want to head on over to the guide (http://perl.apache.org/guide) for Stas' great descriptions of the build procedure and lots of other subjects. Also, I find it easier to build apache statically when doing a mod_perl build. (Others are much bolder than me... ;^) Good luck, Steve Reppucci On Tue, 30 Oct 2001, Rudi wrote: Hi, I'd like to join the mod_perl / apache community. I'm having install problems that I've been trying to solve for 2 days with no luck. So I'd like bother you folks with a beginer question. I'm using Debian 2.2, Apache 1.3.14 and mod_perl 1.24_1. I've tried several times and this is a close as I can get. a) unzip both Apache and mod_perl. b) mod_perl is first : perl Makefile.Pl EVERYTHNG = 1,make,make install. c) Now apache : ./configure --prefix=/usr/local/apache --enable-module=rewrite --enable-shared=rewrite --activate-module=src/modules/perl/libperl.a --enable-shared=perl Everything compiles OK. However, my httpd.conf file now has LoadModule perl_module libexec/libperl.so But this is no libperl.so on my hardrive. I've run updatedb and search but there is no libperl.so. As a result apache will no start ( error about libperl.so ) At work I use Coldfusion,PHP and some CGI with perl. I'm looking forward to getting into mod_perl heaps as perl is a tool I can use for both web development and system admin. Thanks in advance. Kind regards Rudi. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Off-topic - Apache Config - Load crises
I agree with the response that you need to do some statistics gathering to try to accurately isolate the cause of your problems. I *don't* agree with the other suggestion that was made to UP the keepalive to 15-20 seconds (the default that apache comes with is 5, IIRC). Here's why: Assuming that you have one server serving both modperl and image requests, those keepalives are tieing up a large, heavy server, doing nothing but waiting for a new potential request. (Right on to the suggestion to try to get those image requests directed to a separate web server which can be separately tuned...) I actually have a snippet from a writeup I did for a client who was experiencing high server loads about a year ago, here's what I wrote then: - KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 In my experience, the performance killer here is KeepAliveTimeout. This defines the number of seconds that a server child will wait for a client to send additional requests over an already-open connection before closing the socket and making itself available to service other clients' requests - this default value is way too high. Where keep alives work well is in situations where an bunch of requests are likely to occur one after another - such as what's typical when fetching an HTML page containing dozens or more image files served from the same server. Keeping the connection open and serving the HTML page and many of its images without tearing down and re-establishing the connection makes sense here. On a heavily loaded server however, having a server hang around idle, tieing up resources for this long waiting for a new request is wasteful. It's much less of a drain to get that process back into the pool of available child servers as quickly as possible, allowing it to service other requests. This is especially true when you realize that the typical browser tries to optimize its transfers by opening up to four separate TCP connections to the server when loading a page's components, thereby tieing up four child servers. Thinking of the typical client request, where an HTML page is fetched and its referenced images are then also requested, it makes sense to me that these requests are going to come very quickly. It certainly seems reasonable to expect that subsequent component requests will occur in under a second, and that if more than a second elapses without a request, then it's likely that all of the components have been read and the user is likely now reading the page. This being said, I like to set KeepaliveTimeout to its lowest value - '1'. In my not-very-scientific tests, this seems to be the best value to balance the latency experienced by any one client with the overall performance of the server. - Lowering the keepalive did the trick for these people. Disclaimer: I don't have any carefully gathered evidence that this idea (setting keepalive to '1') will do what I postulate it should above. But back when I had access to a large website, with lots of bandwidth, we did some empirical tests that certainly seemed to confirm this idea -- setting a smaller keepalive resulted in better 'ab' numbers. I *did* though send a message to the Apache group, and got a response from Mark Slemko which pointed towards this as a possible issue. A couple of other suggestions: Set Timeout to a lower value (maybe 30?) and decrease MaxClients using the techniques described in Stas' guide. Also, I agree that given the network latency of your site, you might be better off setting the keepalives to a higher value than what I recommend in the above (maybe 2?) I'd love hear others' thoughts on this -- ideas for tuning web servers is a fun topic, afaic...! Steve On Thu, 11 Oct 2001, Rafiq Ismail wrote: I know this is a bit off topic, but I could use some immediate advise on server config? Got a server which is getting hit really bad. Have to keep it up. I've got: P Timeout 300 # Keepalive, better on this server... KeepAlive On MaxKeepAliveRequests100 KeepAliveTimeout5 # performance services MinSpareServers 5 MaxSpareServers 50 StartServers20 StartServers20 MaxClients 250 Pings look like: 64 bytes from x.x.x.x: icmp_seq=0 ttl=244 time=1069.3 ms 64 bytes from x.x.x.x: icmp_seq=1 ttl=244 time=984.8 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=244 time=1138.9 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=244 time=1567.1 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=244 time=1622.3 ms 64 bytes from x.x.x.x: icmp_seq=5 ttl=244 time=1382.8 ms 64 bytes from x.x.x.x: icmp_seq=6 ttl=244 time=1145.5 ms 64 bytes from x.x.x.x: icmp_seq=7 ttl=244 time=1065.6 ms 64 bytes from x.x.x.x: icmp_seq=8 ttl=244 time=1133.6 ms There are some really graphic intensive pages here, however I'm not sure if Keep alive is good when there's lots of contention for pages. Should I: i) disable
Re: [OT] 408 http responses?
I've got a couple of dozen this month -- not sure what the source
is, but they definitely seem to be coming from just a few hosts.
Also, many of mine have no URI in the request, they just seem to
connect and not make any request.
Smells like some time of worm...
On Thu, 20 Sep 2001, Nick Tonkin wrote:
Hi all, sorry to bother, but has anyone else noticed a bunch of 408
(client timed out) requests beginning last evening?
Some but not all of these have also been trying the Nimda exploit. Perhaps
Nimda (or another Micro$oft product) is screwing up the clients?
nick@world /usr/local/apachessl/binperl -e
'open(L,/home/nick/logs/httpd_log); while(L){
chomp;my $r=m/408/?4:m/cmd|root|c\+di/?w:;
if($r){$_=~s/(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*/$1/;$c{$r}{$_}++;}}
foreach(sort{ $c{4}{$a}=$c{4}{$b} } keys %{ $c{4} }){
print$_\t\t[$c{4}{$_}]\t[$c{w}{$_}]\n;}'
207.249.143.170 [1] []
207.160.174.25 [1] []
62.149.161.207 [1] []
62.116.29.17[1] []
207.113.14.149 [1] []
209.129.49.65 [1] []
207.168.157.118 [1] []
207.202.38.140 [1] []
61.134.13.47[1] []
207.113.21.89 [1] []
24.67.119.127 [1] []
209.89.119.5[1] []
199.201.128.19 [1] [2]
207.113.25.50 [1] []
207.42.186.90 [1] []
207.113.25.249 [2] []
207.40.42.66[3] []
207.153.76.249 [4] []
207.241.153.3 [5] []
207.12.40.51[6] [16]
207.183.55.149 [6] []
207.217.138.18 [6] []
207.215.53.116 [7] []
207.152.93.12 [8] []
207.152.93.17 [8] []
207.77.187.76 [8] []
207.71.8.190[8] [384]
207.32.123.115 [9] []
207.252.220.55 [12][]
207.228.113.164 [12][]
207.242.45.234 [12][]
207.71.105.133 [13][112]
207.30.192.101 [14][]
207.248.190.158 [15][]
207.105.76.201 [15][]
207.215.126.141 [15][]
207.232.253.221 [16][]
207.245.74.7[16][]
206.221.254.59 [16][]
207.97.117.43 [16][]
207.208.128.185 [16][]
207.203.42.126 [16][]
207.190.221.23 [16][]
207.227.70.194 [16][]
207.127.178.25 [16][]
207.178.85.42 [16][]
207.153.199.78 [16][]
207.153.229.122 [16][]
207.236.169.100 [16][]
207.88.22.128 [16][]
207.252.1.68[16][]
207.170.35.143 [16][]
207.212.64.137 [16][]
207.76.239.206 [16][]
207.196.218.5 [16][]
207.137.76.119 [17][]
207.71.228.1[91][274]
~~~
Nick Tonkin
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: forbidden vs. cookie
Howdy Ken! I think there are two separate issues here -- there's an expiration time on the cookie, which is your app's instruction to the client as to how long the cookie should be kept. Then there's an expiration time of the ticket represented by that cookie data (to use the Ticket Auth example), which is the length of time the ticket is valid for. The ticket expiration time should be in a (tamper-proof) container encoded within the cookie, and checked by the server side app for freshness with each request. Allowing a client's broken idea of the current time (whether broken through maliciousness or through ignorance) to affect the duration of the ticket's validity is (IMO) a bad thing. If the client's broken idea of the time causes the cookie not to be stored for the correct duration, oh well, that's *their* problem, right? As Tom Christiansen likes to preach Never trust anything sent from the client. Steve On Tue, 1 May 2001, Ken Y. Clark wrote: On Mon, 30 Apr 2001, will trillich wrote: after seeing the 'expires' dilemma brought about by poorly configured client system clocks, what advice should we follow? (what's the Official Party Line on expiring cookies?) I'm not really sure how to answer your question. I have usually understood that the client handles all of this. That is, you tell the client that the cookie is good for 30 minutes, and it figures out when those 30 minutes have expired and then quits sending a valid cookie back to the server. Is that right? Anyone? Anyone? Bueller? -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
