Re: mod_perl suddenly demanding DSO.
>>>>> "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes: Stas> This is not a fatal error. It was fixed in the current CVS Stas> version. Get it from http://perl.apache.org/from-cvs/modperl Thanks, Stas. Bleeding edge here I come :) -- Stephen "So if she weighs the same as a duck, she's made of wood."... "And therefore?"... "A witch!"
mod_perl suddenly demanding DSO.
So shoot me for not hunting through the achives first Upgrading to apache1.3.12 and mod_perl1.2.22 today, I suddenly get the following: apxs:Error: Sorry, no DSO support for Apache available apxs:Error: under your platform. Make sure the Apache apxs:Error: module mod_so is compiled into your server apxs:Error: binary `/tools/web/bin/apache'. Writing Makefile for Apache for every module included the distribution. The error is correct, mod_dso isn't linked into my apache config (never has, never will be). My question is: why is mod_perl suddenly tring to use DSO ? FWIW, the mod_perl build invocation I used is: perl5.00503 Makefile.PL \ APACHE_PREFIX=/tools/web \ APACHE_SRC=../apache_1.3.12 \ DO_HTTPD=1 \ USE_DSO=0 \ USE_APACI=1 \ EVERYTHING=1 \ APACI_ARGS='--target=modperl \ --libexecdir=/tools/web/lib/apache \ --enable-module=info \ --disable-module=asis \ --disable-module=auth \ --disable-module=autoindex \ --disable-module=imap \ --disable-module=userdir' Did I miss something? -- Stephen "A duck!"
Re: mod_perl (DSO) dumping core with perl 5.6.0
>>>>> "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes: Doug> won't performance suffer in that case? i "benchmarked" Perl Doug> malloc vs. system malloc under solaris once, there were far Doug> more syscalls to brk() with system malloc. Ilya has claimed for about 18 mths now that usemymalloc=y is the Right Thing to do on Solaris and that previous assertions that Solaris' malloc is better are no longer true. He claims that perl's malloc is tuned to perl's memory usage patterns resultinging in the lower overhead and supposedly greater speed. That said, I still don't run that way. :) -- Stephen "And what do we burn apart from witches?"... "More witches!"
RE: Why does Apache do this braindamaged dlclose/dlopen stuff?
> So in the longer term, is there a reason the parent has to contain the > interpreter at all? Can't it just do a system call when it needs one? > It seems a bit excessive to put aside a couple of megabytes of system > memory just to run startup.pl. Well, remember that the interpreter itself will remain shared throughout, so there's no real disadvantage in having in the parent. The main reason to run startup.pl in the parent is to overcome as much of Perl's startup time as possible. Compiling the code domainates the startup time, so the thing to do is to pull in your modules in startup.pl . That way, it's only done once, and the results are shared between all children. I think the thing to do here is fix the memory leaks 8-) Stephen.
RE: Why does Apache do this braindamaged dlclose/dlopen stuff?
> -Original Message- > From: Gerald Richter [mailto:[EMAIL PROTECTED]] > Sent: 19 January 2000 04:36 > To: Alan Burlison; [EMAIL PROTECTED] > Subject: RE: Why does Apache do this braindamaged > dlclose/dlopen stuff? > So I would agree to your last sentences that Dynloader is responsible for unloading, because that's > the only module, which knows what it had loaded. Agreed. It's a relatively small change to DynaLoader, with great benefits for embedded Perl. >Also I am not so sure if unloading all the libraries can be really successfully done, because the Perl > XS libraries don't assume that they will ever unloaded (because they are actualy only unloaded when the program exits). > > This may be the reason for memory leaks Daniel metioned earlier, because the XS libraries don't have a chance to > free there resources (or not aware of that they actually should do so). Yes and no. If XS libraries are written with OO-style wrappers (which, IMHO, they always should be), then surely you can catch the unloading in a DESTROY sub and use that to do the deallocation of resources? Perl can only manage Perl resources, and extension resources should be the responsibility of the the programmer. Stephen.
Re: modperl success story
Barb and Tim wrote: > full honesty. The language itself is hard enough to swallow. How is Perl hard to swallow? Perl is so easy and flexible. Stephen
Re: Apache Proxy & Virtual Servers...
>>>>> "Trevor" == Trevor Phillips <[EMAIL PROTECTED]> writes: Trevor> This works fine, except "the.other.machine" gets the Host Trevor> header as "the.other.machine" and NOT whatever is passed Trevor> to the proxy by the client. As a result, virtual servers Trevor> with the same IP but different name are NOT working! Do you actually need virtual hosts in the mod_perl server or would URI namespace spereation accomplish what you want? For instance: ProxyPass/ http://the.other.machine:80/host1/ ProxyPassReverse / http://the.other.machine:80/host1/ ProxyPass/ http://the.other.machine:80/host2/ ProxyPassReverse / http://the.other.machine:80/host2/ -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away"
RE: Another IE5 complaint
> -Original Message- > From: Rod Butcher [mailto:[EMAIL PROTECTED]] > Sent: 23 November 1999 10:20 > Cc: [EMAIL PROTECTED] > Subject: Re: Another IE5 complaint > > > Am I the only battling service vendor who actually feels good when > somebody bookmarks my website ? > I can absorb the overhead of accesses to a favorites icon. > This may be a security hazard for the client, but I detect a > holier-than-thou attitude here against M$. > Will somebody tell me why this M$ initiative is bad, other than for > pre-determined prejudices ? > Rgds > Rod Butcher Speaking as someone who works for an ISP, anything that obscures (by volume) genuine errors is a Bad Thing. The error log is a useful diagnostic tool only if you can see the errors. Yes, you could filter out the requests before examining the file, but the point is MS is making more work for people by being thoughtless. Further reasons it's a bad idea * It's not standard * It's a specific solution to a general problem, and therefore fragile (i.e. it breaks too easily) * It's a quick hack rather than a genuine initiative (which would take effort) Stephen. -- The views expressed are personal and do not necessarily reflect those of Planet Online Limited.
Re: MD5 risks?
>>>>> "Trevor" == Trevor Phillips <[EMAIL PROTECTED]> writes: Trevor> Another alternative is to get the MD5 base64 key to the Trevor> URI. My query is, what is the chance of two URI's giving Trevor> the same MD5? Is there any risk in it, or is MD5 guranteed Trevor> to give unique ID's? (I know the risk would be SLIM, but Trevor> how slim?) Is MD5 used regularly for this kind of thing? What you're asking about is the likelihood of a 'birthday attack' on a given hash. Quoting Bruce Schneier's 'Applied Cryptography', 2nd ed. p166: Finding two [m-bit] message that hash to the same value would only require 2**(m/2) messages This means that if you're worried about a birthday attack, you should use a hash value twice as long as you otherwise might think you need. For example, if you want to drop the odds of someone breaking into your system to less than 1 in 2**80, use a 160-bit one-way hash function. So, with MD5 you have a 1 in 2**64 chance of getting a collision between two URLs. Adding the lenght of the URL doesn't make any practical difference as that's already done as part of the hashing algorithm. BTW, if you plan dealing with any cryptographic-related functions, Schneier's book is a must: ISBN 0-471-12845-7 -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away"
Re: New mod_perl RPM really needed? (was: sourcegarden plug)
Stas Bekman <[EMAIL PROTECTED]> writes: > I think it would help. If you succeed to build a good SRPM for a general > purpose usage, we ether can ask RH to put it in, or can put it on > sourcegarden or perl.apache.org - it's not an issue. Thanks! I found one, actually. On my RH6.0 box at home, I installed an apache+mod_perl SRPM that seemed to work fine. Mod_perl was statically linked in, so I don't have the chaining difficulties. Unfortunately, I had to compile from the SRPM version, since the RPM was compiled for RH5.2, and was therefore looking under the wrong Perl version number for Perl modules. If you look on any RedHat mirror which has the contrib directory, you should be able to find an apache_mod-perl RPM and SRPM. -- Stephen L. Peters [EMAIL PROTECTED] PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "Poodle: The other white meat." -- Sherman, Sherman's Lagoon
Re: modules to be left enabled in a mod_perl back-end server?
>>>>> "Stephen" == Stephen Zander <[EMAIL PROTECTED]> writes: Stephen> Is the SetHandler functionaity of mod_mime available from Stephen> within mod_perl somehow? This was the one ovbious Stephen> problem I could see with removing everything. Nevermind. The Eagle book, chapter 8 p407 is my friend. Stephen goes off to thwap himself unconscious with Doug & Lincoln's excellent book -- Stephen --- "If 8-year-old boys discharging loaded firearms into their own legs isn't necessary to the maintenance of a well-regulated militia, I don't know what is." - Randal Cummings as reported in The Onion, 25/5/99
Re: modules to be left enabled in a mod_perl back-end server?
>>>>> "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes: Doug> I do know that imdb (at one point at least) had nearly every Doug> standard module disabled, leaving just mod_perl, mod_mime Doug> and maybe a logging module. Is the SetHandler functionaity of mod_mime available from within mod_perl somehow? This was the one ovbious problem I could see with removing everything. -- Stephen --- "If 8-year-old boys discharging loaded firearms into their own legs isn't necessary to the maintenance of a well-regulated militia, I don't know what is." - Randal Cummings as reported in The Onion, 25/5/99