Re: strange behavior of Redirect on ajax
On 14 Oct 2005, at 03:50, Roy T. Fielding wrote: I just tried to add Redirect Permanent /dist/jakarta/tomcat http://www.apache.org/dist/ tomcat/tomcat to a .htaccess on ajax and the prefix match/replace didn't work. I had to replace it with RedirectMatch Permanent /dist/jakarta/tomcat(.*)$ http:// www.apache.org/dist/tomcat/tomcat$1 to get the intended results. It makes me wonder if all Redirect directives are broken. :( Noticed the same thing yesterday on one of our sites... Either it was me being a monkey, but Redirect Permanent didn't work, so I used mod_rewrite! Pier smime.p7s Description: S/MIME cryptographic signature
Re: curious write-requests
On 14 Oct 2005, at 09:04, Nathanael D. Noblet wrote: On Fri, 2005-10-14 at 09:01 +0200, [EMAIL PROTECTED] wrote: Hello, we have an extra partition (ReiserFS) for the htdocs directory of our apache 1.3.28 (SuSE 9.0). For performance issues we have monitored our webserver with the tool iostat and recognized many write-requests on the htdocs- partition. Can anyone explain to me where this write-requests do come from? Who is writing and what/why? In a test we requested only static html-pages which can't write temporary files. Nevertheless we had this write-requests. Just a guess but perhaps updating the atime or something like that (last-accessed) time of the file? I know I saw awhile ago a document saying to increase performance to mount noatime on filesystems for web/file serving... We had the same issue a year-or-so ago on one of our Gentoo/Linux boxes running ReiserFS. Mounting the partition with the noatime option fixed it in our case. Pier smime.p7s Description: S/MIME cryptographic signature
[PATCH] Mod proxy not behaving as described in the documentation...
Guys,
going through the mod_cache documentation, i found out that it's
either mis-documented, or there's actually a small bug in the 2.0.52 (and earlier) code.
http://httpd.apache.org/docs-2.0/mod/mod_cache.html#cacheignorecachecontrol:
Ordinarily, documents with no-cache or no-store header values will not
be stored in the cache. The CacheIgnoreCacheControl directive allows
this behavior to be overridden. CacheIgnoreCacheControl On tells the
server to attempt to cache the document even if it contains no-cache
or no-store header values. Documents requiring authorization will
never be cached.
I would interpret this as defining that (for example) if mod_cache is used with
mod_proxy, and the output on the original server contains a Cache-Control:
private value, then mod_cache will ignore what was supplied by the original server
and cache anyway.
Thing is that in the code, the CacheIgnoreCacheControl is _only_ used around
line 113, where we check if the client (not the original document) requires an
uncached copy of the document.
The following patch changes the behavior and forces mod_cache to ignore original documents (or mod-proxy
request) when Cache-Control: private or no-store is present AND CacheIgnoreCacheControl is
Off...
Or should this directive be split into two (like CacheIgnoreCacheControl for the
current behaviour and CacheIgnoreSourceCacheControl for the below mentioned patch) and
patch the documentation as well???
As always, mod_cache is quite important for us at work, so I'm willing to
invest some time on it! :-P
Pier
diff -U3 -r httpd-2.0.52-original/modules/experimental/mod_cache.c
httpd-2.0.52/modules/experimental/mod_cache.c
--- httpd-2.0.52-original/modules/experimental/mod_cache.c 2004-08-26
17:59:44.0 +0100
+++ httpd-2.0.52/modules/experimental/mod_cache.c 2005-01-13
10:26:44.076175720 +
@@ -471,13 +471,15 @@
/* HEAD requests */
reason = HTTP HEAD request;
}
-else if (ap_cache_liststr(NULL, cc_out, no-store, NULL)) {
+else if ((ap_cache_liststr(NULL, cc_out, no-store, NULL))
+ (conf-ignorecachecontrol == 0)) {
/* RFC2616 14.9.2 Cache-Control: no-store response
* indicating do not cache, or stop now if you are
* trying to cache it */
reason = Cache-Control: no-store present;
}
-else if (ap_cache_liststr(NULL, cc_out, private, NULL)) {
+else if ((ap_cache_liststr(NULL, cc_out, private, NULL))
+ (conf-ignorecachecontrol == 0)) {
/* RFC2616 14.9.1 Cache-Control: private
* this object is marked for this user's eyes only. Behave
* as a tunnel.
Re: [proxy] New implementation ready for testing
On 11 Aug 2004, at 17:14, Mladen Turk wrote:
Hi all,
We've finished the initial development of extended mod_proxy.
Since the development took place at jakata-tomcat-connectors,
the source code can be found under ajp/proxy.
Here is the list of major features added:
3. Added new module proxy_balancer
What's wrong with:
ProxyPassReverse / http://localhost:/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule ^/(.*) ${hosts:live}/$1 [P,L]
It's in there already, and it works great (I even have a couple of CGIs
reading and building up that table, enabling, disabling and
prioritizing hosts).
http://wiki.apache.org/cocoon/ApacheModProxy
http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Pier
smime.p7s
Description: S/MIME cryptographic signature
Re: [proxy] New implementation ready for testing
On 16 Aug 2004, at 12:49, jean-frederic clere wrote: Pier Fumagalli wrote: On 11 Aug 2004, at 17:14, Mladen Turk wrote: Hi all, We've finished the initial development of extended mod_proxy. Since the development took place at jakata-tomcat-connectors, the source code can be found under ajp/proxy. Here is the list of major features added: 3. Added new module proxy_balancer What's wrong with: - http is slower than ajp (Therefore the idea of mod_proxy_ajp). Although I don't agree in the AJP protocol, I see the point... - failover. That's a good point! :-P +1 Pier smime.p7s Description: S/MIME cryptographic signature
mod_cache: allowing urls ending in / to be cached
I don't understand why mod_cache forcedly avoids caching URLs ending
with the / (slash) character.
Apparently EGP (who's he?) agrees.
Anyhow, it's several months that we're running with this patch in
production, and nothing bad seems to be happening.
Pier
diff -U3 -wr httpd-2.0.50-orig/modules/experimental/mod_cache.c
httpd-2.0.50/modules/experimental/mod_cache.c
--- httpd-2.0.50-orig/modules/experimental/mod_cache.c
+++ httpd-2.0.50/modules/experimental/mod_cache.c
@@ -79,10 +79,6 @@
cache: URL exceeds length threshold: %s, url);
return DECLINED;
}
-/* DECLINE urls ending in / ??? EGP: why? */
-if (url[urllen-1] == '/') {
-return DECLINED;
-}
/* make space for the per request config */
cache = (cache_request_rec *)
ap_get_module_config(r-request_config,
smime.p7s
Description: S/MIME cryptographic signature
Re: mod_cache: allowing urls ending in / to be cached
On 16 Jul 2004, at 15:13, Graham Leggett wrote: Brian Akins wrote: If it works, I say commit the patch. Can think of no reason why we should not cache an URL ending is /. Because the cache_in filter gets added in the quick_handler. The fast_internal_redirect in mod_dir which translates / to /index.html (or whatever) seems to lose this filter, so it never gets cached. Then I'd say the fix should be to teach mod_dir to not lose the cache filter. As we're not using mod_dir in production, I wouldn't know how that would be affected by it. Pier smime.p7s Description: S/MIME cryptographic signature
Re: [STATUS] (httpd-2.1) Wed Apr 14 23:45:17 EDT 2004
On 15 Apr 2004, at 04:45, Rodent of Unusual Size wrote: * mod_proxy: Ability to run SSL over proxy gateway connections, encrypting (or reencrypting) at the proxy. Does this mean that in 2.1 the SSLProxyEngine on doesn't work anymore? Pier smime.p7s Description: S/MIME cryptographic signature
FW: Apache 2.0.46 Download
Folks, I'm getting _TONS_ of those, can I please ask you kindly to wait at least 24 hours between copying files onto www.apache.org/dist/httpd and announcing it to people? Nagoya is rsyncing every six hours, but even then a lot of people are complaining because the files can't be downloaded. Pier -- Forwarded Message From: phono [EMAIL PROTECTED] Date: Fri, 30 May 2003 10:53:39 +0200 To: [EMAIL PROTECTED] Subject: Apache 2.0.46 Download Hi I am not able to download new apache version for Windows, file called apache_2.0.46-win32-x86-no_ssl.msi could not be found! What's up ... Thx Phono -- End of Forwarded Message
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread?
On 31/3/03 20:59, Jeff Trawick [EMAIL PROTECTED] wrote: I'm using Sun WorkShop 5.0 sometimes, and these builds result in executables like httpd referencing libthread but not libpthread. We pass cc the -mt switch, but at least with this version that switch isn't enough to pull in libpthread. Can anybody confirm that with a more recent Sun compiler APR apps are getting libpthread? This apparently results in apr_proc_create() forking more than just the calling thread, and you can get anoying stuff like this when running Apache's mod_ext_filter with the worker MPM: [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept: (client socket) (By the time the fork()-ed child of the calling thread got around to exec()-ing the external filter program, the copy of the listener thread in the forked() child reached the accept() call.) There was other undiagnosed havoc going on, including a child process exiting with a fatal error code which led to the parent bailing out with a large number of children left to clean up manually. This was probably the neatest failure: ibthread panic: fault in libthread critical section : dumping core (PID: 4894 LWP 12) stacktrace: ff0faaa8 ff0fa8fc ff103498 ff0ff8f0 ff105558 ff2d2bac 36964 ff2d29bc ff10b728 ff2d2978 Cool, huh? I haven't gotten to the point of teaching APR to pull in libpthread in this situation and rebuilding Apache's httpd and retesting, but I thought I'd put this out there to see if somebody with a newer compiler is getting better results. Jeff/all... We got Forte on Nagoya, thanks to the freaks @ Sun! :-) /opt/forte/ Pier
Servlet API changes and mod_proxy...
The new upcoming servlet API will include some new methods to retrieve the connection IP and PORT in case of proxied HTTP requests. It will be basically required to obtain the following: - IP + PORT of the remote client - IP + PORT of requested by the client - IP + PORT where the request was received by the server (the latter are different in case you have a proxied request, because you can get both the IP + PORT of the proxy server where the original request was received and the IP + PORT of the servlet container where the proxied request was forwarded to). Would it make any sense to extend the already-present capability of mod_proxy with X-Forwarded-... headers to include the original client port number and the IP + PORT of the Apache instance receiving the original request? The X-Forwarded-For would contain something like 192.168.1.2:19876 (instead of just the first bit before the ':'), and I would need to add another header containing the IP of the client connection (I was thinking about something like: X-Forwarded-Address: 10.0.0.1:80 What do you guys think? pier
Re: Servlet API changes and mod_proxy...
Pier Fumagalli [EMAIL PROTECTED] wrote: The new upcoming servlet API will include some new methods to retrieve the connection IP and PORT in case of proxied HTTP requests. It will be basically required to obtain the following: - IP + PORT of the remote client - IP + PORT of requested by the client - IP + PORT where the request was received by the server (the latter are different in case you have a proxied request, because you can get both the IP + PORT of the proxy server where the original request was received and the IP + PORT of the servlet container where the proxied request was forwarded to). Would it make any sense to extend the already-present capability of mod_proxy with X-Forwarded-... headers to include the original client port number and the IP + PORT of the Apache instance receiving the original request? The X-Forwarded-For would contain something like 192.168.1.2:19876 (instead of just the first bit before the ':'), and I would need to add another header containing the IP of the client connection (I was thinking about something like: X-Forwarded-Address: 10.0.0.1:80 What do you guys think? Forget about the second part... That should be the Via header, right? Pier
Re: any Solaris 9 users out there with worker MPM?
On 12/3/03 1:02, Jeff Trawick [EMAIL PROTECTED] wrote: any experiences good or bad to share? ISTR that the default thread library changed with Solaris 9... did that expose any glitches wth worker? None whatsoever so far... Not live yet, but the development environment runs already on 9, and I haven't seen any issue. Can't vouch for speed though... Perceived is roughly the same (but that's testing our entire application, not only the web server with side-by-side comparisons between 8 and 9). Pier
FW: Apache 2.0 download problem
Got a ton of those lately... It's proably because http://nagoya.apache.org/mirror/httpd/binaries/win32/ Advertises that the last stable version is 2.0.43, while in the files we have 2.0.44... Pier -- Forwarded Message From: Daniel Trifonov [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Fri, 28 Feb 2003 03:20:50 -0800 To: [EMAIL PROTECTED] Subject: Apache 2.0 download problem Hi Pier, I've just tried to download the last distribution of the Apache web server (for Win32) from several download mirrors (including your servers), but the link to the distribution package httpd-2.0.43-win32-src.zip seems to be broken! Where can I get the software? Free 20MB Web Site Hosting and Personalized E-mail Service! Get It Now At Doteasy.com http://www.doteasy.com/et/ -- End of Forwarded Message
Re: Apache 2.0
Thom May [EMAIL PROTECTED] wrote: * Guntupalli, Santhi ([EMAIL PROTECTED]) wrote : Hi, Currently I am using HTTP Apache WebServer 1.3.9 with apache JServ 1.0 or 1.1 . I want to move to HTTP Apache (because multi threaded support) WebServer 2.0.43.Does Apache 2.0 support any of Apache JServ versions which is 1.0.x or 1.1.x. Or any other alternate to use JServ with Aache 2.0.43. Anybody has any pointers??. Urm, you should perhaps look at upgrading from JServ to Jetty or Tomcat since JServ has not had any development for many years. The only way you will be able to run jserv with apache2 is to port the module yourself, or find someone else who will do it... For sure Jserv is the strongest servlet container on this planet, I don't blame Santhi if he wants to still use it! :-) But yeah, the problem is the module, and I don't have spare cycles to even look into it :-( :-( Pier (happy to see that his baby is still used)
Re: Solaris 8 + gcc 3.2.1 + libtool = fuckup...
On 5/1/03 8:31, Aaron Bannert [EMAIL PROTECTED] wrote: Ah yes, I know this problem. The problem is simply that you are using gcc with solaris' built in ld while ld doesn't implicitly link against libgcc.a. I consider this to be a gcc bug. Well, no, it's not a GCC bug, as if you link any executable using GCC it _will_ work... The problem is that libtool doesn't use GCC for linking libraries, but rather relies on the native Solaris LD, which (of course), doesn't know about libgcc.a... If instead libtool used GCC for linking, then GCC would invoke the same LD but automagically specifying the libgcc.a thing on the command line (if you do it manually and use verbose compilation, you'll see that it is actually passed as a parameter to LD). You already figured out the first workaround, which is to stick libgcc.a in your ld parameters. To make this slightly more maintainable you can stick this at the end of your ld params: `gcc -print-libgcc-file-name` I don't know if this would work, but you might be able to put that in your LDFLAGS when running configure. I tried this, _but_ it won't work... If you specify the library in the LDFLAGS, libtool will refuse to create shared libraries if one of the objects is an AR archive (as libgcc.a)... It will build the modules, but all of them will simply be AR archives (and that ain't good). This has nothing to do with libtool nor autoconf. It _has_ to do with libtool, because if I compile the module using GCC straight, without passing through libtool, the module will compile fine and will work as well... I have some more lengthy replies about this problem in the bugzilla database. I'm sure you could search for __floatdisf in there and find my postings. I will... Thanks for helping Aaron... Pier
Solaris 8 + gcc 3.2.1 + libtool = fuckup...
Again, here goes my little problem :-( I'm trying to compile 2.0.43 on a Solaris 8.0 (latest patches) machine, using gcc-3.2.1 (which I compiled) and the libtool coming in the dist (no, I didn't re-run buildconf), and I have one problem. Let's start by saying that my gcc is compiled with --enable-static --disable-shared (which is going to make things complicated), so libgcc is only available as libgcc.a (no libgcc.so). As I compile on a development machine, and deploy on another, I don't want to bring libgcc.so around, so, with everything else, it works... Now, the problem is the following: when I compile httpd, and try to invoke httpd -t, it'll simply refuse to load saying: Cannot load /opt/apache/modules/mod_status.so into server: ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file /opt/apache/modules/mod_status.so: symbol __floatdisf: referenced symbol not found This also happen with mod_auth_digest.so... Tracing down the problem, it seems that libgcc defines __floatdisf, but the ./configure process never figures out that it'll need to link certain modules against it. The odd thing (odd, well, its ANOTHER libtool bug) is that when I specify LDFLAGS=-lgcc to configure, all modules are created as static libraries (because libtool cowardly refuses to link something against a static and a shared library)... Now, gcc _correctly_ links any executable to the correct library libgcc.a automagically (if I call it from the command line), _but_ libtool is stupid, and assumes that when we want to link a library, we can simply call ld automatically without caring about what GCC might have to say... And then I get into a deadlock... To compile mod_status and mod_auth_digest, I need to use libtool, but libtool calls ld directly without the inclusion of libgcc, so, basically, I'm foobared... My quick-and-dirty solution was to call LD myself adding libgcc on the command line and manually re-link the two modules, but I bet that I'm not the only one who will get into this problem as HTTPD-2.0 gets deployed more widely (this doesn't happen with 1.3). I haven't tried with Justin's jlibtool (as it doesn't want to work against the latest 2.0.43, darn) but if someone wants to do what I did, and use libgcc static, is going to run into troubles... Now, I tried to do two things: link httpd including libgcc and adding libgcc.a to libapr... They both don't work, so, at the end, I'll have to hack every module depending on something defined by libgcc (apxs won't work for those modules)... Anyone got a friggin' CLUE? Throw me a bone out here! :-) :-) BTW, if someone wants an account on the troublesome set of machines, just let me know... :-) Pier
FW: Older version of apache2
Folks, given that httpd is mirrored worldwide and not all mirrors are actually rsyincing the .old directory (or anything that starts with a . for what that matters), can you change the link in README.html to point to http://www.apache.org/dist/httpd/.old; instead of just a relative to .old? Cheers... Pier -- Forwarded Message From: Maarten van den Dungen [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 12:29:44 +0100 To: [EMAIL PROTECTED] Subject: Older version of apache2 Hi, I am looking for an older version of apache2 (2.0.39), because I get a conflict with php. This older version seems to work. Your link on the following page doesn't seem to work. http://nagoya.apache.org/dist/httpd/binaries/win32/ What can I do? Thanks. Regards, Maarten -- http://www.shortcut.nl/ mailto:[EMAIL PROTECTED] -- Shortcut Software Development B.V. Apeldoornseweg 49, 6814 BJ Arnhem, The Netherlands. Phone: +31 (0) 26 446 44 52 Fax: +31 (0) 26 446 44 51 --- Disclaimer -- This message may contain information which is privileged or confidential. If you are not the named addressee and you received this message in error, please contact the sender and delete it from your computer without disclosing its contents to any other person. All services are subject to the general conditions of SSD BV, which provide for a limitation of liability. The general conditions are available upon request. They have been filed with the Chamber of Commerce at Utrecht. -- End of Forwarded Message
Before I start a new module...
Ok, I was kindly asked by my management to write a new module for Apache 2.0, since as of _TODAY_ we're using it in production for non-static content as well (whoho!)... Before I move all my apps over on the new Apache 2.0 server, I need to be able to strip whitespace from HTML (ok, my designers like using DreamWeaver, not my fault), so since I can use filters, well... :-) First question would be... Seems pretty odd that noone thought about it before (???), so, is there a module doing that already? If not, am I right in looking at what mod_bucketeer does for a start? Cheeridos! :-) Pier
Re: Before I start a new module...
On 25/11/02 1:52 am, David Crooke [EMAIL PROTECTED] wrote: Why not just strip them once on install, instead of every time they are downloaded? You could hook something into ftp or whatever the Dreamweaver kids are using for upload, or a cron to come and sweep stuff, keeping track of what's processed using a timestamp file. Nonono :-) The dreamwever kids use dreamweaver to create JSP templates (evill) so, I am _not_ serving files off disk, I mean, I'm stupid, but not _that_ stupid! :-) :-) :-) Plus JSPs leave a _lot_ of crap around in files, like, several newline characters where there shouldn't be any... And so on... It's just a _stupid_ templating system, but what the heck, they pay me to accept my designers, so... :-) Since I already don't have a Content-Length header (since I don't know how much content I'm going to shoot out), and my boss is concerned about mod_deflate not being supported by (like) Netscape 1.3.1 when Javascript is disabled (or some stuff like that, a customer is a customer), well, got no options left... Pier
Re: new download page
On 27/10/02 19:26, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Sat, 26 Oct 2002, David Burry wrote: ftp://ftp.apache.ddns.develooper.com/pub/apache/dist/ should find an Apache mirror not on the other side of the world. We want downloads working with HTTP... Anyhow, how do you do that? Can we move the logic on Apache.ORG so that something like mirror.apache.org will be pointing at your closest mirror? (You should improve it, I end up in hungary 19 hops, but got some mirrors at 5/6)... Pier
Re: new download page
Erik Abele wrote: +1. great idea, but I think the mirror sites should be mentioned more than only once. Agreed, it's one of those things I hate most of SourceForge... I _always_ screw up, copy the link from my browser to my terminal on the wget command line parameter, and end up with a few-kb long HTML file... I'd say that it should be more visible that the link is an HTML rather than a TARball... Something like Click here to find out where you can download HTTPD-2.0.43.tar.gz from... I know, I'm dumb! :-) Pier
Re: new download page
On 27/10/02 0:04, Joshua Slive [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: I'd say that it should be more visible that the link is an HTML rather than a TARball... Something like Click here to find out where you can download HTTPD-2.0.43.tar.gz from... Ewww... Ugly. I'm open to suggestions on improving the transparency, but I don't like that one. It would be easy enough if it was only one or two files, but it is hard when we need to present it clearly for many files. Ok, as long as it's clear! :-) I'm very dumb, but I know other people smarter than me who also have the same problem with SourceForge... You simply forget! :-) Pier
Re: new download page
On 27/10/02 0:54, David Burry [EMAIL PROTECTED] wrote: I agree that a link on a tar.gz (etc) filename is a lot more intuitive if it serves an actual tar.gz file... What about a script that randomly redirects to an actual mirrored file? I realize it may be necessary to monitor all mirrors to automatically take them in and out of the loop when they're up and down, but still I also wish there was a way to automatically detect which one is actually closer and fastest network-wise too... hmm.. This is probably getting to be too complex of a suggestion for anyone to do with volunteer time and resources but still just an idea... ;o) I looked into it back in the days, but the only way would be to go down to RIPE (IANA in the US) to see where that IP is coming from, doing some weirdo WHOIS parsing and stuff... _WAY_ overkilling... Anyhow this is going waaay offtopic! :-) Pier (having nothing better to do than work and reply-to email tonight)
Re: httpd restart on daedalus and more redirects
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've redirected more content to nagoya due to our recent performance problems on daedalus. Namely, jakarta.apache.org/builds/jakarta-tomcat-40/release, jakarta.apache.org/builds/jakarta-ant/release, and the three most popular httpd source tarballs under www.apache.org/dist/httpd/ (httpd-2.0.43.tar.gz, httpd-2.0.43-win32-src.zip, and apache_1.3.27.tar.gz). I chose these URLs because they were responsible for eating a lot of bandwidth on Oct 20. I did this via a non-graceful restart because an httpd buglet wouldn't allow us to raise the number of httpd child processes. Now daedalus response is a lot better, but nagoya seems a little slow. If this keeps up, I will un-redirect a few URLs via graceful restart. Pier, how do things look to you on nagoya? Things on nagoya do not look good at all... I mean, the uptime is low, but for some wicked random reason, it maxes out the bandwidth on the interface I don't get it... It looks like everything is going allright over there, but at a certain point it starts loosing packets, as if the ethernet was saturated... I don't get it... _really_ don't get it... Unless (but that can't happen even in my wildest dreams) someone didn't put up a HUB on nagoya instead of a switch It's odd though... If I had a hub over there (10 mbps plain old hub), I wouldn't be able to even get to the console (tokio.betaversion.org), but apparently, I can get to the console allright (it's on the same subnet), but I can't get to nagoya... Could it be a broken ethernet interface? I don't know, I don't really think so, as it always performed great... But as soon as someone is down at Sun I'll have them switch the ethernet over onto the secondary IF just to see if that's the cause... When it rains, it pours, they say, ain't it? Pier
Re: apache.org getting DoS'd? maxclients turned down
On 21/10/02 21:14, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Well, I don't feel brave enough to redirect all of that at once without knowing what's going on in the xml or jarkarta projects, and without being able to monitor nagoya very well. Greg, if you want I can open up you an account... But I did add: Redirect /dist/httpd/binaries http://nagoya.apache.org/dist/httpd/binaries And we're beautifully serving binaries at a rate of 20/30 per minute! :-) I'll keep the situation under control as we go! :-) :-) GO worker/MPM! Pier
Re: distributing encryption software
On 19/10/02 14:35, Jeff Trawick [EMAIL PROTECTED] wrote: I can't install Solaris 8 from a recent enough CD-ROM set that has sendfile if I want to do Apache 2.0 binbuilds which are usable by the general Solaris 8 user community (you can't even download sendfile+prerequisites without a maintenance contract last time I tried). Hmm... You can download the latest version of Solaris, boot from the CD, and for PACKAGE in `pkginfo -r /a` ; do pkginst -r /a /Products/$PACKAGE ; done (expand the obvious bits where the stuff wouldn't work)... Basically you're going to replace the whole OS with a new one, or you can just replace a couple of packages (SUNWcor and SUNWcorx)... Ok, it's a hack, but what the heck! :-) Heck, even with Win32 there aren't many people who can do binbuilds, and that is particularly bad when a security fix is announced and everybody looks for the same one person. And given that MSVC costs $, the problem gets bigger... If there were money (thanks for downloading the latest Apache binary distribution for your platform; would you care to contribute a few euros towards the generation and availability of what you just downloaded?), it would be possible to maintain a set of machines running the appropriate set of system software to enable binbuilds to be reliably built for the largest possible audience. If a loosely affiliated group (unencumbered friends of Apache) could accept contributions and maintain a rich set of binbuilds of Apache with/without SSL support, a lot of users would be happier and a lot of PRs could be closed with less hair turning gray but without breaking the user (I'm sorry you are encountering this particular build SNAFU. It works fine for a number of people on that platform. There is a trusted binary build for your platform available from www.xx.org.). More than what you were interested I'm sure, but there are other frustrating aspects of binbuilds than just the encryption issue. Well, I don't think that you need $$$, the only thing you really need is hardware (for the builds), bandwidth (for downloads) and time (to build)... The unencumbered friends of Apache could put time, hardware can be donated (a nice web page saying if you want a binary build for AIX, give me a nice IBM box), and bandwidth can be sponsored by someone (I mean, as long as you put down a nice Thank you to LINK for donating the bandwidth)... I'm sure that (at least in the UK) someone like Clara.NET, Level3, or even Demon would like the idea... Pier
Whopsie on Darwin/Mac OS X 10.2.1... :-(
Just tried to compile on Darwin/Mac OS X 10.2.1, and 2.0.43 doesn't want to build modules (darrrn)... It simply copies the .la file and doesn't even think about creating a .so... Will look into it... :-( Pier
Re: Whopsie on Darwin/Mac OS X 10.2.1... :-(
On 7/10/02 20:57, Sander Temme [EMAIL PROTECTED] wrote: Just tried to compile on Darwin/Mac OS X 10.2.1, and 2.0.43 doesn't want to build modules (darrrn)... It simply copies the .la file and doesn't even think about creating a .so... We seem to have the following in the tarball: [MonaLisa:~/projects/httpd-2.0.43] sctemme% srclib/apr/libtool --version ltmain.sh (GNU libtool) 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) Well, that is HOSED as it doesn't contain any -bundle stuff to create libraries under Darwin... It simply doesn't work under Mac OS X. What happens if you run ./buildconf and then reconfigure make? It recreates srclib/apr/build/libtool.m4 (DOH!) :-) Seriously speaking, the glibtool distributed with Darwin is _again_ hosed (I don't know what to do next, I'm going to hang myself to some loose rope hanging around here), how many times do I have to send patches to _world_ about it Ok, anyhow, I patched my local copy (again and again and again), rerun ./buildconf, and everything works like a charm... Of course I don't use Fink (because it sucks badly), I just rely on the standard Mac OS X installation, so, I get whatever apple gives me (bugs included)... Now, this is the patch I had to make against my live system to make it work: [foobared mailer, see attachment, which _of course_ will be encoded in friggin' base 64, don't complain, I know, but I paid several hundred $$$ for Office X and now I better use it] I see two options, either I come up (again) with my own LibTool package and put it up on Apache.ORG (the copy I had was moved off to another server and that server DIED, thanks J.F.Clere for noticing), or we distribute another copy of the source files (only for MacOS/X) for 2.0.43 (after I've applied the patch, and re-buildconf-ed)... For 2.0.43 the latter seems the best option (I'm going to do that on www.apache.org/~pier/), for the future, it's probably better to have the glibtool-patched-package ready, and also make sure that the glibtool we use doesn't suffer from such bugs) AH I hate this world :-( Pier (who had a _terrible_ day today, can you tell) glibtool.patch.txt Description: Binary data
Re: Whopsie on Darwin/Mac OS X 10.2.1... :-(
On 7/10/02 21:45, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 03:27 PM 10/7/2002, Sander Temme wrote: Your HEAD probably uses the glibtool(ize) installation on your local box, which on 10.2 by default is 1.4.2. The tarball was built using the FreeBSD libtool, which is 1.3.4. This version did not know about Darwin yet and will not create any sort of shared library on this platform. The solution is building the tarball with a more recent version of libtool. Maybe Apache should fail more conclusively if the user wants .so modules and the build system can't do them, but that's a different question from getting the functionality to work. I think the ASF roll environment should bump its libtool. I doubt Darwin is the only platform that would benefit from that. This is my doing. Suggestion; could you offer a patch to build/httpd_roll_release that warns the RM that the version of buildconf is too stale? Checking against 1.4.2 would be a good-thing(TM) indeed, but doesn't guarantee that on certain platforms (such as darwin, where the mainstream libtool port doesn't work) this will not break things again... We've been playing the libtool game since I started building 2.0. At one point or another, it broke things (I remember AIX as well), and as far as I know, noone has ever been able to get a patch incorporated into the main tree (I mean, removing a couple of is not a big deal, right?)... We can't keep libtool on our CVS as it's GPLed, let's just keep it off somewhere, apply the patches _we_ need, and keep our machines updated with _our_ version which works _for_us_... Right? And yes - updating all the Apache machines would be convienent. If my ex-girlfriend decides to give me back my Cube, I might be able to keep it as an Apache Server for development and Testing on MacOS/X, since it seems that moof is completely unmaintained... Pier
Re: Whopsie on Darwin/Mac OS X 10.2.1... :-(
On 7/10/02 22:02, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've got a better idea. Let's just get jlibtool doing enough so that we can use it everywhere. :-) +1 Downloading it off _now_ (That's where Justin's stuff was... ;-) Pier
Re: Whopsie on Darwin/Mac OS X 10.2.1... :-(
On 7/10/02 22:06, Sander Temme [EMAIL PROTECTED] wrote: I've got a Jag box that I use for my testing. Pretty clean install... Want a user account? Thanks, but my cube would be my 4th Mac box :-) And actually the server (since it's so quiet!) Pier
Re: [PATCH] caching and query strings
Kris Verbeeck [EMAIL PROTECTED] wrote:
apr_status_t cache_generate_key_default( request_rec *r, apr_pool_t*p,
char**key )
{
- *key = apr_pstrdup(p,r-uri);
+ *key = apr_pstrcat(p,r-uri, ?, r-args, NULL);
return APR_SUCCESS;
}
Hm... This should be something like:
If (r-args) {
*key = apr_pstrcat(p,r-uri, ?, r-args, NULL);
} else {
*key = apr_pstrdup(p,r-uri);
}
But I might be severely stupid...
Pier
Re: [PATCH] caching and query strings
Paul J. Reder [EMAIL PROTECTED] wrote: Yes, I believe it should check r-args. I don't think you are stupid, severely or otherwise... ;) That's what _you_ think... Others (like me) tend to disagree! :) After thinking about it, it wouldn't really matter, because apr_pstrcat will already stop at the first NULL argument passed... The only problem I see in that approach would be that two requests: http://www.myserver.com/blah? and http://www.myserver.com/blah would end up with the same key blah?\0 if you don't check for that beforehands (but I don't know exactly how the http stack would parse the first request)... I believe this is ignorable... Pier
Re: perchild under Solaris 8
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yeah, I don't think Solaris uses the same structure/functions for passing fd's between processes. I had originally planned to use a Solaris box for the second port, but I don't have access to one yet. I keep looking on e-bay for a good x86 box though. Ryan, send me your SSH key... We have _plenty_ of Solaris boxes (including a big fat Apache machine handling the bug tracking database!!! :) :) :) NO EXCUSES! :) :) :) Pier
Re: El-Kabong -- HTML Parser
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. It makes a lot of sense to have it also in XML as well, together with XERCES-C... Pier
Re: perchild on FreeBSD 5?
Rasmus Lerdorf [EMAIL PROTECTED] wrote: Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? I agree, and I have been preaching the same thing for a while. Almost no point in releasing Apache2 without a working perchild. Unfortunately there are other issues as well. A lot of the 3rd party libs that something like PHP or mod_perl depends on are not necessarily threadsafe. As witnessed by FreeBSD's incredibly buggy threading code there aren't a lot of things using threads heavily on UNIX. With some notable exceptions, of course, but very few try to pull in 30 or 40 3rd-party libraries as well. We are going to have to fix a bunch of them and mutex some others before Apache2 with a threaded MPM will be of any use with PHP or mod_perl. And I am not sure how to go about identifying the libraries that aren't qiute threadsafe. Problems generally only show up under load and only in certain circumstances. Especially for the libraries that claim to be threadsafe but aren't quite for whatever reason. Luckily, in Java land things are more or less brighter, and I can say that for what matters to me (I don't use PHP on big production servers, apart from a couple of things which are thread safe - IMP and related), the threaded MPM is giving me nothing but joy every single friggin' day! :) Keep up the gud staf guys! :) Pier (working his ass off on a deadline!)
Remember to update BugZilla when...
Rolling new releases! :) 2.0.40 was not in there... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11607 It's now fixed! :) :) :) Pier
Re: Tests failing????
Ryan Bloom [EMAIL PROTECTED] wrote: I know that there has been some talk of doing a release next week. I just ran my test suite, and we seem to be failing some mod_access checks. I think it has to do with the table re-write, but I haven't looked at it in enough detail to be 100% sure. Is anybody else seeing this problem? FWIW, I still see a lot of processes which must be killed -9 with worker at shutdown... Same as .32, both on Sol8 and on OS/X... Pier
Re: MacOS X 10.1.2 libtool
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Any one seen this error, on a pristine MacOS X 10.1.2 machine with a freshly cut 2.0.39: cd httpd-2.0.39 ./configure --prefix=/foo make make install cd ../test apxs -c mod_foo.c and then just before then end one gets: /foo/runtime/build/libtool --silent --mode=link cc -o mod_auth_pam.la -rpath /Users/dirkx/ORA/runtime/modules -module -avoid-version -I/usr/local/include -L/usr/local/lib mod_auth_pam.lo -lpam /foo/runtime/build/libtool: parse error: condition expected: xyes = [3183] /foo/runtime/mod_auth_pam-1.1/apache-2.0/.libs SH_LIBTOOL='/foo/runtime/build/libtool' mod_auth_pam.la ... But.. this does result in a functional module. To add to the insult: running apxs or buildtool with 'sh -x script' in an attempt to trace this error makes the error vanish in thin air. Libtool shipped with MAC doesn't actually produce a MH_BUNDLE dylib... Use mine http://www.apache.org/~pier/macosx/ Pier
Re: Auth - how much legacy to preserve ?
Dirk, since you're working on a patch for Auth, would it be possible to have the groups list somewhere in the request structure? It would be great with web applications, where we can match groups with roles (therefore allowing authentication to be processed by apache entirely)... Pier [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: While doing this patch (and ending up with 3 very small modules); I found the following legacy behaviour. Any feels as to if we shall kill these surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?: -if there are no requires - but there is Auth happening we actively OK. - If there are no requires for the method (but there are requires for that directory for other methods) we actively OK. -If we have for example a (Group,..)File but opening it failes then we ignore any 'require group' and DECLINE to other modules. Proposal to fixing these leaks (comment now or wait for code) and allowing small footprint modules to take part of the process over: -mod_auth_file auth UserID/passwd against file DECLINE if no file configured ERRORif file read error (was DECLINE/UNAUTH) OKif ok DECLINE if UID not found non-authoritative UNAUTHotherwise -mod_auth_groupfile checks UserID against required 'require (valid-)group' DECLINE if no requirements at all (was OK) DECLINE if no group file configurued ERROR if file read error (was IGNORE) OKif in a group DECLINEif no applicable method requirments (was OK) DECLINE if no recognized method requirements DECLINE if not authoritative and not in recognized groups. UNAUTH otherwsie -mod_require_user checks UserID against required 'require (valid-)user' DECLINE if no requirements at all (was OK) OK if in the list /valid user DECLINE if no applicable method requirements. (was OK) DECLINE if no recognized requirements DECLINE if there are lists, not in list but non authoritative UNAUTH otherwise And then - to get closer to the old apache: -mod_auth_default auth DECLINEif no Basic Auth header/r-user. DECLINE if not authoritative UNAUTH otherwise checkDECLINEif no r-user OK if no requires (*) OK if no applicable method requirements (*) DECLINEif not authoriative UNAUTHotherwise *: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from 1.3; An alternative would be to not do this and change to always UNAUTH then when there is r-user information provided and not authoritative. I do want to allow fall through - so that a perl/php/java backend is able to get access if/when needed. Thus: -apache core authOK checkOK Of course - the mod_auth_default could also be in the core of the http proocol handling. Does this make sense ? Dw. -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Auth checker - long term goal..
Ryan Bloom [EMAIL PROTECTED] wrote: I'm sorry, but that is completely bogus. If the API needs to change to make things better, then change the API. Stop trying to open a new dev branch when the current one is still moving forward quickly. We have this discussion every few weeks now, and every few weeks the 2.1 repo gets shot down, because these changes belong in 2.0. I tend to agree with Ryan although I'm no committer... Wouldn't want to see httpd to end up like Tomcat did... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Auth - how much legacy to preserve ?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 10 Jul 2002, Pier Fumagalli wrote: Dirk, since you're working on a patch for Auth, would it be possible to have the groups list somewhere in the request structure? It would be great with web applications, where we can match groups with roles (therefore allowing authentication to be processed by apache entirely)... Well - r-user, or any r-credentials are valid there; as they come from the protocol; i.e. are part of the request. The group information can, depending on protocol, come from more than one source - provided with the credentials (e.g. like the 'account' dimension in ftp or your kerberos realm). - a user can belong to N groups as returned by an all knowing auth system when asked. - a check if the user was in a list of M groups can have yieled that he was a member of P groups which is a subset of M. Once you add group; there are other dimensions too; i.e. think of the login.conf resources on BSD, a much more mature framework like that on mainframes, and so on. So this is perhaps a bit more complex than just that. What is it you would feel as most useful in the web application world - could you elaborate ? Indeed it is complex... Basically, a web application in java land specifies some security constraints in the web.xml file (its deployment descriptor). It relies on two main concepts: user (doh!) and a thing called role which is more or less the parallel of a group. Each user can have zero-or-more of these roles (can be in zero or more groups with the current mod_auth). Given the idea that I want my entire web site to be controlled by (let's say) a single user/groups database, I need to pass to the servlet container the list of roles to which every user is associated with, therefore its list of groups, because at any time (even if the servlet is not under any particular security constraint), someone might call the isUserInRole call, and verify if a user is actually in a particular group... I can do that passing the list of groups to the roles to the servlet container, or calling back Apache and if mod_auth could provide a hook to verify a particular user/role association, that would be even great... Does this make sense? Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Apache Worm
Jon Travis [EMAIL PROTECTED] wrote: On Sun, Jun 30, 2002 at 11:24:30PM +0200, [EMAIL PROTECTED] wrote: On Sun, 30 Jun 2002, Pier Fumagalli wrote: Rasmus Lerdorf [EMAIL PROTECTED] wrote: I assume everyone has seen this? http://dammit.lt/apache-worm/ Me and Fede are running through the decompiled assembly code right now... Will let you know what we find out (it looks kinda odd from the look of it). I found several. Source under private cover. You mean apache-worm.c, posted on that URL 5 lines up from your reply? That's been out there for a while. Nope... I believe Dirk is referring to the fact that that is ONE of the exploits, but there are some others coming around... :( :( :( Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Apache Worm
Rasmus Lerdorf [EMAIL PROTECTED] wrote: I assume everyone has seen this? http://dammit.lt/apache-worm/ Me and Fede are running through the decompiled assembly code right now... Will let you know what we find out (it looks kinda odd from the look of it). Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: CAN-2002-0392 : what about older versions of Apache?
Bill Stoddard [EMAIL PROTECTED] wrote: Some wrote... ... I must say I'm mystified by this discussion. It seems to be an odd argument between this good practice vs that good practice. Roy's patch is simple, safe, and reduces the exposure substantially to a known threat. I can't see any reason to defer letting it out; particularly now that people have been given a few days to give voice to any technical concerns about it. The worst outcome is that we are embaressed - we can handle that. Certainly it's a good thing to be careful. Giving the right folks a chance to look over a patch for stuff like this is a good thing. Careful is good. It's a lot easier to be careful before the exploit becomes widely known. Leaving the users with no option but to stay exposed, write their own patch, or upgrade is pretty stern medicine for us to be proscribing. It is very hard for some sites to upgrade. Let's put the patch back. +1 Yes please... As Bill knows we have a problem with the WebSphere module which is only supposed to run on 1.3.6 (with our version of WebSphere, anyway)... Given that we're sending that baby in retirement in 2 months, we didn't renew with IBM, sooo... We're bummed! :) :) :) Pier (we - my employer and I) -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Apache 2.0 Numbers
Rasmus Lerdorf [EMAIL PROTECTED] wrote: Up from 397 requests/second but still nowhere near the 615 requests/second for Apache 1.3. But, doing this buffering internally in PHP and then again in Apache doesn't seem efficient to me, and the numbers would seem to reflect this inefficiency. Rasmus... I was chatting with Ryan on IRC today, and in my case (I have a document which is approx 11 Kb long), Apache 2.0.39/worker on Solaris/8-intel actually outperforms Apache 1.3.26 with the same PHP 4.2.1 (well, the one for Apache 2.0 uses Apache2Filter from PHP HEAD)... It's a good 10% faster than 1.3... (If people are interested in numbers, I'll rerun the tests. When RBB told me he expected those results, I /dev/null ed em...) Pier
Re: daedalus pegged
Greg Ames [EMAIL PROTECTED] wrote: Cliff Woolley wrote: Well, I guess our security advisory worked. Daedalus is totally maxxed out at 700 concurrent requests holy cripe! (which I assume is the maxclients setting). yep. MANY people downloading the new releases of Apache (expecially 1.3.26.tar.gz and the win32 binary of the same version). Good to see our efforts taken seriously. It's back down to 560 now. We've got a bunch of headroom available on MaxClients, but I don't want to bump it up a huge amount at times like this without watching it closely. Thanks for the heads up. I'm rsyincing now the distribution over onto nagoya... Given it's an *.apache.org machine, I believe that people might feel more safe to download it from there... I'm adding a mirror to our set... One other thing we might want to consider is putting a link to the download site over onto the httpd site, pointing to /dist, with something like A href=httpd://www.apache.org/dist/httpdUpdate NOW!/A Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: FINAL STATUS FOR THE NIGHT
1.3.26-dev (head from 12:48 GMT) is up and running on our main VNUNET site (Solaris 7/sparc) and it looks great. It chomped some million requests already... Pier
Re: FINAL STATUS FOR THE NIGHT
Pier Fumagalli [EMAIL PROTECTED] wrote: 1.3.26-dev (head from 12:48 GMT) is up and running on our main VNUNET site (Solaris 7/sparc) and it looks great. It chomped some million requests already... As it turned out later, we had to get back to 1.3.14 because of a problem in either mod_proxy+mod_rewrite, or our servlet engine module... Pier
Re: [STATUS] apache 1.3 and 2.0 nearing release
William A. Rowe, Jr. [EMAIL PROTECTED] wrote: 1.3.25 was DOA, the last minute changes to ap_strtol were mildly borked [explaining Pier's frustration.] All 1.3.25 images are redacted from /dev/dist/. So, are you saying that you found out why I was requesting http://www.vnunet.com/News and I was getting back http://www.vnunet.com/Search or some other random page? :) :) :) Pier
Re: [TEST] Apache 1.3.26 Release Candidate for Testing
Can't build on MacOS/X (I am being silly now!)... $ ./configure \ --prefix=/Library/Services/Apache \ --enable-module=most \ --enable-shared=max Configuring for Apache, Version 1.3.26 + using installation path layout: Darwin (config.layout) Creating Makefile Creating Configuration.apaci in src + enabling mod_so for DSO support Creating Makefile in src + configured for Darwin platform + setting C compiler to cc + setting C pre-processor to cc -E -traditional-cpp + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End enabling DBM support for mod_rewrite o dbm_auth_module uses ConfigStart/End + using builtin Expat + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in src/support Creating Makefile in src/regex Creating Makefile in src/os/unix Creating Makefile in src/ap Creating Makefile in src/main Creating Makefile in src/lib/expat-lite Creating Makefile in src/modules/standard Creating Makefile in src/modules/proxy $ make [.] cc -bundle -undefined suppress -flat_namespace -o mod_alias.so mod_alias.lo cc -c -I../../os/unix -I../../include -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite `../../apaci` -DSHARED_MODULE mod_rewrite.c mv mod_rewrite.o mod_rewrite.lo /usr/include/ndbm.h:63: header file 'db.h' not found /usr/include/ndbm.h:83: undefined type, found `DB' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode make[4]: *** [mod_rewrite.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[1]: *** [build-std] Error 2 make: *** [build] Error 2 Why the hell is db.h not there? RGHH Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: [TEST] Apache 1.3.26 Release Candidate for Testing
Pier Fumagalli [EMAIL PROTECTED] wrote: Can't build on MacOS/X (I am being silly now!)... I AM being silly... My bad, I fucked db.h... Reinstalling the developer tools made the trick... :( Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Are we +1 for 1.3.26 and 2.0.38?
William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 06:02 PM 6/18/2002, William A. Rowe, Jr. wrote: Fast feedback to irc://irc.openprojects.net/#apr channel, or simply reply here. This isn't a long vote, say, the next 15-30 minutes. jwoolley, pier, brian pane, (me) all +1 by IRC Continuing the tally for a few more minutes. Confirmed to be running on MacOS/X without any apparent problem. For the URL stuff (now that the router seems to be fixed), I will check back tomorrow, but from few tests I've made, I suspect it's allright... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Status line problems...
Folks, I don't really get this one... Maybe someone can enlighten me. Stefan is using mod_webapp on HP_UX, with Apache 1.3.23. WebApp sets the status line in the request_rec structure, doing something like: if (status !=NULL status[0]!='\0') req-status_line=apr_pstrdup(req-pool,status); Now, it happens that when that line is in place, oddly enough, the response seen by the client instead of being HTTP/1.1 XXX My Message Goes Here comes out as HTTP/1.1 My Message Goes Here basically dropping the status error code... I can't reproduce this locally, but it seems to be happening on HP-UX. Is anyone aware of a bug like this? If we don't set request_rec-status_line, everything seems to work pretty well... If you have any hint let me (and Stefan, on CC) know, it's a week we're trying to sort this out! :) :) :) Thanks! Pier
Re: 2.0.37 ready to release?
Cliff Woolley [EMAIL PROTECTED] wrote: From all accounts I've heard (except the one tiny snafu on ReliantUnix), 2.0.37 is working nicely. +1 for GA from me. It is... No weirdness on nagoya so far on Sol8/worker... Pier
Re: Status line problems...
Justin Erenkrantz [EMAIL PROTECTED] wrote: On Thu, Jun 13, 2002 at 11:24:51AM +0100, Pier Fumagalli wrote: Folks, I don't really get this one... Maybe someone can enlighten me. Stefan is using mod_webapp on HP_UX, with Apache 1.3.23. WebApp sets the status line in the request_rec structure, doing something like: if (status !=NULL status[0]!='\0') req-status_line=apr_pstrdup(req-pool,status); Now, it happens that when that line is in place, oddly enough, the response seen by the client instead of being HTTP/1.1 XXX My Message Goes Here comes out as HTTP/1.1 My Message Goes Here What is status (your string) in this case? It would be My Message Goes Here The status_line field should contain the code as well as the text message. The r-status field isn't automatically prepended to the status_line. -- justin A FU*KME! :( I wasn't able to reproduce it because I wasn't setting the status line on darn Tomcat... Folks I _AM_ stupid... Justin, go to bed! :) Pier
Worker + MaxClient ...
I just recompiled the latest HEAD on nagoya, and doing some performance analysis One thing I noticed is that when someone hits MaxClients, performances go down to be dog-slow... IIRC, this was a known bug of Worker, but wasn't it supposed to be fixed? I'm currently trying it out with a 64-bits compiled binary, but will do the same once the 32-bits one gets baked... It just looks really weird.. Pier
Re: Worker + MaxClient ...
Pier Fumagalli [EMAIL PROTECTED] wrote: I just recompiled the latest HEAD on nagoya, and doing some performance analysis One thing I noticed is that when someone hits MaxClients, performances go down to be dog-slow... IIRC, this was a known bug of Worker, but wasn't it supposed to be fixed? I'm currently trying it out with a 64-bits compiled binary, but will do the same once the 32-bits one gets baked... It just looks really weird.. From time to time, 3 times over 10k requests today for manual/index.html, 2.0.38-dev as of this morning segfaults when it is compiled at 64bits under Solaris-8, with lightweight processes used instead of threads, and concurrency greater than 1000... But it didn't dump the core, so, can't do much with it (still need to find out all those nice CC flags for Sun's compilers)... BTW, when running with the default threading library, it works just fine. Here are some results of the tests... The machine is an E450 with 10 Mbps of network, 1 gig ram, and 2 UltraSPARC/II-400 processors... The remote client is an ultra 5 connected on the same hub... The relevant part of the configuration are: StartServers4 ThreadLimit 256 ThreadsPerChild 256 MaxRequestsPerChild 0 Then it's all default... Have fun... --- 64 BIT REMOTE - Concurrency Level: 1000 Total transferred: 104587192 bytes Requests per second:89.47 [#/sec] (mean) Transfer rate: 935.73 [Kbytes/sec] received Concurrency Level: 100 Total transferred: 103015852 bytes Requests per second:95.86 [#/sec] (mean) Transfer rate: 987.51 [Kbytes/sec] received --- 32 BIT REMOTE - Concurrency Level: 1000 Total transferred: 104265004 bytes Requests per second:92.75 [#/sec] (mean) Transfer rate: 967.06 [Kbytes/sec] received Concurrency Level: 100 Total transferred: 102898755 bytes Requests per second:96.28 [#/sec] (mean) Transfer rate: 990.75 [Kbytes/sec] received --- 64 BIT LOCAL -- Concurrency Level: 100 Total transferred: 10284 bytes Requests per second:538.77 [#/sec] (mean) Transfer rate: 5410.81 [Kbytes/sec] received Concurrency Level: 100 (LWP) Total transferred: 10284 bytes Requests per second:482.60 [#/sec] (mean) Transfer rate: 4846.72 [Kbytes/sec] received Concurrency Level: 1000 Total transferred: 10284 bytes Requests per second:95.62 [#/sec] (mean) Transfer rate: 960.35 [Kbytes/sec] received Concurrency Level: 1000 (LWP) [Segmentation fault] Total transferred: 10284 bytes Requests per second:99.77 [#/sec] (mean) Transfer rate: 1001.95 [Kbytes/sec] received --- 32 BIT LOCAL -- Concurrency Level: 100 Total transferred: 10273 bytes Requests per second:522.13 [#/sec] (mean) Transfer rate: 5238.06 [Kbytes/sec] received Concurrency Level: 100 (LWP) Total transferred: 10273 bytes Requests per second:547.79 [#/sec] (mean) Transfer rate: 5495.51 [Kbytes/sec] received Concurrency Level: 1000 Total transferred: 10273 bytes Requests per second:91.36 [#/sec] (mean) Transfer rate: 916.54 [Kbytes/sec] received Concurrency Level: 1000 (LWP) Total transferred: 10273 bytes Requests per second:99.43 [#/sec] (mean) Transfer rate: 997.46 [Kbytes/sec] received Pier
Re: --with-mpm=worker on freebsd
Doug MacEachern [EMAIL PROTECTED] wrote: why is it on freebsd --with-mpm=worker actually compiles the prefork mpm? i just tried building on icarus with the 2.0.37 tarball, same thang with 2.0.36 % cat config.nice #! /bin/sh # # Created by configure CFLAGS=-g; export CFLAGS ./configure \ --prefix=/home/dougm/apache2-worker \ --with-mpm=worker \ $@ % ~/apache2-worker/bin/httpd -V Server version: Apache/2.0.37 Server built: Jun 11 2002 10:18:20 Server's Module Magic Number: 20020602:1 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork ... % ~/apache2-worker/bin/httpd -l | grep prefork prefork.c Hmm.. The latest HEAD distribution works great on solaris with worker $ /opt/apache/bin/httpd -l | grep worker worker.c $ Pier
Re: tarballs are up for testing
Cliff Woolley [EMAIL PROTECTED] wrote: On Tue, 11 Jun 2002, David McCreedy wrote: Are there tarballs for 1.3.25 or just 2.0.37? Just 2.0.37. Though I'm having a bit of trouble with the 2.0.37 tarball... it might be bogus. I untarred it as myself on icarus and ran my ./config.nice... it went fine up until the end, where I got lots of this kind of message: config.status: creating docs/conf/httpd-std.conf mv: docs/conf/httpd-std.conf: set owner/group (was: 1259/0): Operation not permitted config.status: creating include/ap_config_layout.h mv: include/ap_config_layout.h: set owner/group (was: 1259/0): Operation not permitted This might be a symptom of having used autoconf 2.53. I might need to yank this tarball and do it with a lesser autoconf version. Will keep investigating. Hmm.. Just downloaded the tarball and the ./configure script runs fine... The only thing I noticed is that if instead of running the shipped ./configure, I regenerate it with autoconf-2.53, then it complains in all possible sort of ways... Pier (building right now)
Re: tarballs are up for testing
2.0.37 is up and running on Nagoya.Apache.ORG... For this one I just used GCC 3.1 in 32 bits mode (it's the main install and I don't want to screw up things too quickly! :) Logs can be seen in /opt/apache/logs for those who have accounts and are interested... Pier root@nagoya] /opt/apache/conf $ cat /opt/apache/conf/httpd.conf [...] IfModule worker.c LockFilelogs/accept.lock ScoreBoardFile logs/apache_runtime_status PidFile logs/httpd.pid StartServers4 ThreadLimit 256 ThreadsPerChild 256 MaxRequestsPerChild 0 /IfModule [...] root@nagoya] /opt/apache/conf $ /opt/apache/bin/httpd -V Server version: Apache/2.0.37 Server built: Jun 11 2002 11:03:39 Server's Module Magic Number: 20020602:1 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_MMAP -D APR_USE_PROC_PTHREAD_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=/opt/apache -D SUEXEC_BIN=/opt/apache/bin/suexec -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf [root@nagoya] /opt/apache/conf $ /opt/apache/bin/httpd -l Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_log_config.c mod_env.c mod_setenvif.c worker.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_asis.c mod_cgid.c mod_negotiation.c mod_dir.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_so.c
Re: tarballs are up for testing
Cliff Woolley [EMAIL PROTECTED] wrote: On Tue, 11 Jun 2002, Pier Fumagalli wrote: Hmm.. Just downloaded the tarball and the ./configure script runs fine... The only thing I noticed is that if instead of running the shipped ./configure, I regenerate it with autoconf-2.53, then it complains in all possible sort of ways... Via buildconf, you mean? What kinds of things do you see? WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. Pier
Re: tarballs are up for testing
Cliff Woolley [EMAIL PROTECTED] wrote: Yeah, that's pretty annoying. But it still works. :) Does it? The first thing I did was to step back to 2.52... Ok, then... Since I reinstalled it now, I'll keep it and ignore the warning... :) Pier
Re: 2.0.37-dev/Solaris-8/sparc-v9
Ian Holsman wrote: BTW.. you do know that 64bit programs take a ~10% hit in performance don't you? The JVM seems a lot faster (perceived performance, no actual data on hand) at 64 bits rather than 32... Pier
2.0.37-dev/Solaris-8/sparc-v9
I'm about to attempt to build Apache 2.0.37-dev at 64 bits with the Sun C compiler (kindly donated by Sun), on Nagoya (worker MPM). Anything I should be aware of? I'll report back on how the baby flies (if it does)... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: 2.0.37-dev/Solaris-8/sparc-v9
Aaron Bannert [EMAIL PROTECTED] wrote: On Wed, Jun 05, 2002 at 09:17:46PM -0400, Jeff Trawick wrote: Pier Fumagalli [EMAIL PROTECTED] writes: I'm about to attempt to build Apache 2.0.37-dev at 64 bits with the Sun C compiler (kindly donated by Sun), on Nagoya (worker MPM). Anything I should be aware of? I'll report back on how the baby flies (if it does)... There is an open PR about a 64-bit build on Solaris. IIRC, the atomic stuff adds some v8plus flag that the linker doesn't like. See PR 9247. If you build and install on the same machine the atomics bug shouldn't a problem. (I still opt for a hypothetical --enable-nonportable-atomics flag and have it be portable by default, FWIW.) Yeah, build and deploy on the same box... The only problem is that the compiler won't install without an X-display... Darn idiots! :) Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Tagging 2.0.37
Ian Holsman [EMAIL PROTECTED] wrote: Sander Striker wrote: Hi, What about tagging the tree on monday? Thoughts? FWIW the worker MPM in 2.0.36 is broken and will deadlock under high loads. Can you wait until we make sure that brian's patch fixes it? I would also like to see the hi-free apr-pool patch in as well I can set it up on Nagoya, but up until now, we never hit that much load to make 2.0.36 die... Will do it tomorrow... Pier
[PATCH] little configure.in quoting problem....
It _should_ go with quotes as well, but in M4, we'd better use [] square brackes, am I right? Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] patch-configure.in.txt Description: Binary data
Re: Self-contained modules?
Justin Erenkrantz [EMAIL PROTECTED] wrote: Got a bit of an interesting problem I encountered with Darwin and building PHP the other day. I brought this up on the php-dev list and I'd like to consider what our options are to fixing this. First off, Darwin requires that all modules be self-contained by default. So, if we try to build with PHP with apxs, we will get symbol not defined errors for all of the apr and apr-util functions. This can be turned off by -flat_namespace -undefined suppress - see [EMAIL PROTECTED]. But, for certain reasons the PHP developers would prefer to use bundles instead - the approach Apple uses outlined in Sander's post above. So, we have a few alternatives and I'd like to post them here to see what we think the preferred solution is before replying on php-dev. 1) Tell PHP tough - they must use -flat_namespace. Problem solved. 2) Teach PHP about apr-config and apu-config so that they know where APR is and can link them when building the module. I think the problem would be solved. 3) Have APXS expose apr and apr-util in a consistent manner so that it is possible to build self-contained libraries. In email exchanges with a PHP developer (Marko?), he really didn't like option 1 or 2. He would like to see #3. Personally, I say #2, but I'd like to see what everyone else thinks. -- justin Hmm... AFAIK, building mod_webapp, libtool under darwin has several troubles in linking against a static and a dynamic library (two at the same time)... It simply doesn't want to pass the stupid -all_load parameter to the compiler. Under WebApp we solved it by not creating AR libraries, but simply linking all the .lo files all together with APXS (see my latest patches on that), and of course, the idiot won't build a dso with all symbols correctly referenced if you don't build a library named libsomething.la... Go figure, libtool sucks. BTW, related to this, anyone tried to build mod_proxy under Darwin? Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: 2.0.36 release
Jeff Trawick [EMAIL PROTECTED] wrote: Cliff Woolley [EMAIL PROTECTED] writes: +1 for GA. Let's get this bad boy out the door. +1 from me too No segfaults on worker un nagoya whatsoever... The only thing nagging me is: [Mon May 06 00:01:15 2002] [warn] child process 18743 still did not exit, sending a SIGTERM [Mon May 06 00:01:15 2002] [warn] child process 18744 still did not exit, sending a SIGTERM [Mon May 06 00:01:15 2002] [warn] child process 18744 still did not exit, sending a SIGTERM [Mon May 06 00:01:16 2002] [warn] child process 18744 still did not exit, sending a SIGTERM [Mon May 06 00:01:21 2002] [error] child process 18744 still did not exit, sending a SIGKILL [Mon May 06 00:01:37 2002] [notice] SIGHUP received. Attempting to restart [Mon May 06 00:01:38 2002] [notice] Apache/2.0.36 (Unix) mod_webapp/1.2.0-dev configured -- resuming normal operations Not always processes die nicely... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: 2.0.36 release
Cliff Woolley [EMAIL PROTECTED] wrote: On Mon, 6 May 2002, Pier Fumagalli wrote: No segfaults on worker un nagoya whatsoever... Great! Thanks for testing it out. Was about time that we updated HTTPd on there... And Nagoya is the perfect place to test out multi-threaded stuff (6 procs on Solaris 8) The only thing nagging me is: [Mon May 06 00:01:15 2002] [warn] child process 18743 still did not exit, sending a SIGTERM Not always processes die nicely... Yeah, that's a known nastiness with 2.0.36's worker. At least it shuts down, though. We'll clean it up for 2.0.37. Was also in 2.0.35... It's just a PITA because you have to wait 30 secs before doing a startup if one of the children didn't die... -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: Apache 2.036 Drop
Cliff Woolley [EMAIL PROTECTED] wrote: On Sat, 4 May 2002, Anthony W. Marino wrote: Where can I find this at so that I can test TC4.1/Apache2 integration? 2.0.36 has not been released yet. You can find a test tarball at http://httpd.apache.org/dev/dist/ though. BTW, we have 2.0 and Tomcat together already in production: http://nagoya.apache.org/ Works fine... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: [PATCH] apxs.in
Jeff Trawick [EMAIL PROTECTED] wrote: Pier Fumagalli [EMAIL PROTECTED] writes: This is (again) Thom's patch to make APXS work when we don't use standard layouts, and we move things around after building... a few comments/questions: 1) application/octet-stream attachments are a pain I'll try to figure out how to deal with those kind of attachments under OS/X. Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
[PATCH] apxs.in
This is (again) Thom's patch to make APXS work when we don't use standard layouts, and we move things around after building... It works great on Darwin, if someone could possibly check that out and review, that would be absolutely fantastic... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick apxs.in.patch.txt Description: Binary data
[FINDINGS/PATCH] --enable-shared=moduleA moduleB not working onDarwin...
context file=STATUS * --enable-mods-shared=foo1 foo2 is busted on Darwin. Pier posted a patch (Message-ID: [EMAIL PROTECTED]). /context Naya... Doesn't work -AT-ALL-... It looks like a bug in /bin/sh which on Darwin is ZSH or some major misunderstanding between that and autoconf. It really looks like that given a parameter like '--enable-mods-shared=a b' with a space and quoted with single quotes (or double quotes, FWIW), _somewhere_ that thing gets expanded in two parameters... Now, linking /bin/sh with /bin/bash (my package), makes everything work, although I wasn't really able to make a test case (it seems to work from the command line, but once you get around in autoconf's madness, something gets really wacky, both with Autoconf 2.13 - default on darwin - or my version of 2.52)... Therefore, I believe that to make it work we'll need to wait for 10.2 where /bin/bash will be the default shell (whohooo!). Or (patch attached) change the behavior of --enable-modules and --enable-mods-shared. Instead of having a whitespace separated list of module, we can have a comma separated list, and that will work on Darwin with both Autoconf 2.13 and 2.52, and I tested it on solaris 8 as well with Autoconf 2.13... The patch to configure.in, instead, is just a little m4 fix for a wrong (IMO) evaluation of double quotes arguments (shouldn't it be made with [ ] instead???) Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick patch-acinclude.m4.txt Description: Binary data patch-configure.in.txt Description: Binary data
Re: an old Darwin issue... what is the solution?
Jens-Uwe Mager [EMAIL PROTECTED] wrote: On Sat, Apr 20, 2002 at 08:15:17AM -0400, Jeff Trawick wrote: Gregory (Grisha) Trubetskoy [EMAIL PROTECTED] writes: This fixed it, thanks. Seems to me though that httpd ought to know where the libs are without my help :) I think Pier Fumagalli explained it recently. IIRC, the need for the envvar is because we link against the libraries before they were installed. I don't remember whether or not we discussed the appropriateness of setting DYLD_LIBRARY_PATH in the envvars file that apachectl uses. It would seem to me to be a reasonable thing to do. Isn't the -install_name option to the Darwin libtool supposed to handle that case? This way you can embed the final install destination in the shared library. Yes, and that what it does with MY version of GNU libtool... He seems to be using the one shipping w/ the developer tools... Big -1 on setting DYLD_LIBRARY_PATH in ENVVARS... That's just a hack... Pier
Re: PHP Bugz...and other extra noise
Joshua Slive [EMAIL PROTECTED] wrote: On Fri, 12 Apr 2002, Andreas Hasenack wrote: Em Fri, Apr 12, 2002 at 10:40:16AM -0700, Joshua Slive escreveu: Is there any way to make the search box on the main page search both open and closed reports? At the moment, it does not search closed reports. If not, it should probably be noted explictly. Build that query, and then choose to remember it, giving it a name. Next time you will get a combo box with this query in it. Just select it and hit query. That would work if I wanted a query for myself. But I'm most concerned about having a query for people to use before they submit bug reports. In addition, the query on the main page is special, in that it applies the submitted keywords simultaneously to a bunch of different fields. I think there is a special cgi script behind it, but I haven't looked in detail. I have no clue on how that (CRAP) of Bugzilla works... Anyone welcome to go thru the sources... Pier
Re: PHP Bugz...and other extra noise
Done... William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Can we provide the following text from the bugzilla welcome page http://nagoya.apache.org/bugzilla/ ... even if we place it below the usual buttons? [If it should appear below the first page's form, a big link to #policies at the top of the page would be nice.] Do NOT submit a problem report without searching the existing ones first to ensure that the issue you are reporting has not already been addressed Do NOT send configuration questions or requests for help debugging your installation, locate the appropriate users support mailing list or newsgroup instead. Do NOT report security vulnerabilities through this form! Send all security vulnerability reports via email to [EMAIL PROTECTED]. Do NOT send questions about security or configuration to either [EMAIL PROTECTED] nor this bug forum, send such questions to the appropriate users support mailing list or newsgroup. Do NOT report bugs in PHP, use the PHP Project's bug reporting database at http://bugs.php.net/ If you're tracing spam or you're here because one of your favorite Web sites now says 'It Worked! Apache is installed!' -- then contact the mail originator or the Web site's Webmaster directly, because they're just using our software and we have nothing to do with them. Don't waste your time or ours by telling us about it. Finally, before submitting your first report, DO read the bug submission guidelines at http://nagoya.apache.org/bugzilla/bugwritinghelp.html Following the guidelines will assure the bug is resolved much more quickly. Any comments or objections?
Re: Autoconf 2.52 on Darwin?
Justin Erenkrantz [EMAIL PROTECTED] wrote: Has anyone else tried to run configure off of an autoconf-2.52 produced configure on Darwin? It fails for me when it tries to go to the srclib/apr configure due to it trying to pass 'CFLAGS=-Wall -g' as a command-line argument (I did pass that to httpd's configure, so it should propogate to apr, apr-util, etc.). Is this another quoting problem related to zsh? Am I nuts? Going back to autoconf 2.13 works. -- justin [pier@blossom] ~ $ autoconf --version autoconf (GNU Autoconf) 2.52 Written by David J. MacKenzie. Copyright 1992, 1993, 1994, 1996, 1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [pier@blossom] ~ $ Works for me... Never had a problem... I _believe_ it might be a problem related to the little patch I sent 3/4 days ago in some APR m4 functions... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: an old Darwin issue... what is the solution?
Jeff Trawick [EMAIL PROTECTED] wrote: Roy T. Fielding [EMAIL PROTECTED] writes: See also http://fink.sourceforge.net/doc/porting/libtool.php Thanks for the link to fink. It looks useful in general, beyond the libtool information. I didn't have any trouble* getting either Sander's or Pier's solution working once Sander told me about DYLD_LIBRARY_PATH :) Pier's solution results in a cleaner build (a bunch of bogus basename invocations went away). Neither version of libtool gets the library path into httpd for some reason (Darwin limitation?). That's odd... With my most recent build: $ otool -L /Library/Services/Apache2/Binaries/httpd /Library/Services/Apache2/Libraries/libapr.dylib /Library/Services/Apache2/Binaries/httpd: /Library/Services/Apache2/Libraries/libaprutil.0.dylib /Library/Services/Apache2/Libraries/libapr.0.dylib /usr/lib/libSystem.B.dylib /usr/lib/libdb.3.3.11.dylib /Library/Services/Apache2/Libraries/libexpat.0.dylib /Library/Services/Apache2/Libraries/libapr.dylib: /Library/Services/Apache2/Libraries/libapr.0.dylib /usr/lib/libSystem.B.dylib It _is_ in HTTPD... (Or you're thinking about something else?) The only thing I complain about now is versioning (done by libtool, it's all so screwed)... *other than wasting a fair amount of time because APR configure bombs when I use --enable-mods-shared=foo1 foo2 foo3 foo4 Perhaps the logic to build the command-line for the APR sub-configure is busted on Darwin... more research required :( Hmm... Can you give me some more info? What's wrong with it? Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: an old Darwin issue... what is the solution?
Chuck Murcko [EMAIL PROTECTED] wrote: On Thursday, April 11, 2002, at 02:41 PM, Pier Fumagalli wrote: Jeff Trawick [EMAIL PROTECTED] wrote: The only thing I complain about now is versioning (done by libtool, it's all so screwed)... *other than wasting a fair amount of time because APR configure bombs when I use --enable-mods-shared=foo1 foo2 foo3 foo4 Perhaps the logic to build the command-line for the APR sub-configure is busted on Darwin... more research required :( Hmm... Can you give me some more info? What's wrong with it? Pier do you also exclude the pcre lib from the build? This is also required on 1.3 (--disable-rule=WANTHSREGEX). Nope... Oddly enough now that you mention it, PCRE is built as a nonshared library (ar archive, I suppose) And it complains a little bit for a duplicate definition of if when it links. Apparently at the end doesn't get compiled in (otool -rv /usr/sbin/httpd2 doesn't contain any reference to the regexp functions)... Is that a problem? The baby runs fine :) Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: an old Darwin issue... what is the solution?
Jeff Trawick [EMAIL PROTECTED] wrote:
Pier Fumagalli [EMAIL PROTECTED] writes:
Jeff Trawick [EMAIL PROTECTED] wrote:
Pier's solution results in a cleaner build (a bunch of bogus
basename invocations went away). Neither version of libtool gets the
library path into httpd for some reason (Darwin limitation?).
That's odd... With my most recent build:
I was apparently misinterpreting a symptom :) My
understanding/experience was that I had to set DYLD_LIBRARY_PATH to
get the libraries found from the non-default location. I figured that
was because the executable din't have the right search path built in.
But if the path is in httpd as you show, that shouldn't be the case.
I'll try again when I get a moment.
Nah, you don't need DYLD_LIBRARY_PATH configured... The Mach-O library
structure is very well done, once you get around and actually understand how
it works, you can just basically build anything you like and forget about
broken libs dependancies...
The only problem is doing it right, check out some of my patches on my home
page for the packages: for BerkeleyDB I have to re-link the libraries at the
end of the process because they don't get built right with their makefiles,
but then they work like a breeze anywhere you want to put them...
You should only need DYLD_LIBRARY_PATH when you linked against a library
which was in one place, and have been moved elsewhere after you built...
*other than wasting a fair amount of time because APR configure bombs
when I use --enable-mods-shared=foo1 foo2 foo3 foo4
Perhaps the logic to build the command-line for the APR sub-configure
is busted on Darwin... more research required :(
Hmm... Can you give me some more info? What's wrong with it?
Here's an example symptom:
cut here
trawick@localhost:~/apache/httpd-2.0% rm *cache
trawick@localhost:~/apache/httpd-2.0% ./configure --prefix=/tmp/gobble
--enable-mods-shared=autoindex dir
creating cache ./config.cache
checking for chosen layout... Apache
checking host system type... powerpc-apple-darwin5.3
checking target system type... powerpc-apple-darwin5.3
checking build system type... powerpc-apple-darwin5.3
Configuring Apache Portable Runtime library ...
updating cache ./config.cache
configuring package in srclib/apr now
loading cache /Users/trawick/apache/httpd-2.0/./config.cache
checking host system type... Invalid configuration `dir': machine
`dir' not recognized
checking target system type... Invalid configuration `dir': machine
`dir' not recognized
checking build system type... Invalid configuration `dir': machine
`dir' not recognized
Configuring APR library
---cut here
Freaky ! :) Gotcha... It's an error in line 82 of
srclib/apr/build/apr_common.m4... Debugging it it comes out as:
/Users/pier/Desktop/httpd-2.0/srclib/apr/configure --prefix=/tmp/gobble
'--enable-mods-shared=autoindex dir' --cache-file=/dev/null
--srcdir=/Users/pier/Desktop/httpd-2.0/srclib/apr --prefix=/tmp/gobble
--exec-prefix=${prefix} --libdir=${exec_prefix}/lib
--includedir=${prefix}/include --bindir=${exec_prefix}/bin
--datadir=${prefix} --with-installbuilddir=${datadir}/build
You see how --enable-mods-shared=autoindex dir is quoted? Well, the
problem is that that sucker is not expanded by a shell (DOH), so the two
parameters are read as '--enable and dir'...
Patch to make it work:
cvs server: Diffing .
Index: apr_common.m4
===
RCS file: /home/cvspublic/apr/build/apr_common.m4,v
retrieving revision 1.29
diff -U3 -r1.29 apr_common.m4
--- apr_common.m4 23 Mar 2002 16:18:35 - 1.29
+++ apr_common.m4 11 Apr 2002 21:26:34 -
@@ -79,7 +79,7 @@
esac
# The eval makes quoting arguments work.
- if eval $ac_abs_srcdir/configure $ac_configure_args
--cache-file=$ac_sub_cache_file --srcdir=$ac_abs_srcdir $2
+ if eval /bin/sh -c $ac_abs_srcdir/configure $ac_configure_args
--cache-file=$ac_sub_cache_file --srcdir=$ac_abs_srcdir $2
then :
echo $1 configured properly
else
--
I think that it's extremely foolish to name a server after the current U.S.
President. B.W. Fitzpatrick
Re: DO NOT REPLY [Bug 7910] New: - WSADuplicateSocket onstarting the server
William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Dunno the right forum, so we can start here. But a bugzilla@ list might be worthwhile, so we don't task those watching infrastructure@ and get some cross-project discussion going. Can we change the Subject to quit wrapping the description of the bug, and move most of the DON'T REPLY fooness to the end of the message? These 'features' make browsing emails of bug reports very tedious. A better solution might be to munge the Reply-To to something like [EMAIL PROTECTED] ... so it's evident. Can't do that in BugZilla... Even two liner at the top (with a link to the bug) would be better than 10 lines today that include the subject duplicated right off the bat within the mail body, once as Subject: (cool) and duplicated two lines above that reference (redundant). There's no way to change the format of the BugZilla emails... Only some rough controls, but not much... FINALLY, THE ALL CAPS THING IS REALLY, REALLY ANNOYING. Bill, I understand your grief, but you understand mine... With all those warnings, it's already a PITA because I usually end up with 10/15 idiots a day replying to those messages... When I just had one line, the idiots were 10/15 a DAY!... I'm going to accept the change only if someone volunteers to respond to the idiots, and take over for the [EMAIL PROTECTED] alias... Pier
Re: 2.0.35 for Darwin was Re: where to describe critical
Ryan Bloom [EMAIL PROTECTED] wrote: The problem is that when we went to libtool, we called this out as a problem (in fact, many people said they had seen this happen before). The group's decision was that we could just make it happen. If we need Sascha to submit the patches, then let's ask him to do it. If that still doesn't work, then we have a bunch of intelligent developers on this list. We can re-write libtool so that we aren't dependant on a group of developers who don't want external help. A BIG F**KING +1 ON THE REWRITE... The versioning idea behind it is just way-too-bogus to even be fun! :) And no, I'm not volunteering to do it! :) Pier (GNU LibTool is worse than BugZilla)
Re: Bug report for Apache httpd-1.3 [2002/04/07]
Graham Leggett [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: | 7195|Opn|Blk|2002-03-18|mod_proxy removes Set-cookie headers | This bug is fixed - how does one update bugzilla? Is there an idiots guide anywhere? Create a new account with your email addy, log in, and change the bug! :) It's self explainatory after you log in :) Pier
Re: 2.0.35 binaries for Linux boxes
GOMEZ Henri [EMAIL PROTECTED] wrote: -Directory @@ServerRoot@@/@rel_errordir@ +Directory @rel_errordir@ Those will screw up the whole httpd.conf in some cases... You should really use @exp_..dir@... Pier
Re: 2.0.35 binaries for Linux boxes
GOMEZ Henri [EMAIL PROTECTED] wrote: I agree that many site put everything under ServerRoot, but when you specify in config.layout that DocumentRoot goes under /var/www2/html, you don't want to see the final httpd.conf under /etc/httpd2/var/www2/html Yeah... Ok... That's why I said to use @exp_dir@ instead of @@ServerRoot@@[EMAIL PROTECTED]@... Try replacing those values in your httpd.conf.in, and rerun ./config.status, and tell me if it works (since I was the one who made that part of the change)... Arg so it was you ;) Who do you think causes troubles all the time? For now, I 'cowardly' made major replacement in httpd.conf.in via sed to be sure my RPM will works on my Redhat 6.2 and 7.2 and will try the @exp_...dir@ later, may be tomorrow... so should I replace for example ? @@ServerRoot@@/@rel_logfiledir@ = @exp_logfiledir@ Yup... You can also check what comes out of your installed config_vars.mk, to see whether that value is correctly set or not... Pier
Re: ApacheCon scheduling was Re: cvs commit: httpd-dist KEYS
Justin Erenkrantz [EMAIL PROTECTED] wrote: Especially now that we went GA on 2.0, we should meet to discuss 2.1 or 3.0... Waiting until Nov will just suck. -- justin I'm going to get a gun now! :) Before talking about 2.1, I (and I know I'm voicing concerns of _a_lot_ of people) would really _love_ to see 2.0 settle down for a little while... At least for the sake of us poor module-writers :) :) :) Pier
Re: httpd-2.0 policies was Re: ApacheCon scheduling
Justin Erenkrantz [EMAIL PROTECTED] wrote: Well, there are a number of issues that I think we'd need to hash out before thinking about what comes next. Should we open 2.1 now? I don't think so. But, should we in three or four months? Perhaps - it depends how 2.0 goes. Good... You scared the bejesus out of me :) A much more important question that we need to start thinking now about is how set are we on this module API? Are we going to allow changes to go into 2.0 that require module authors to modify their code? I believe I'm pretty dead set against that. 2.0 API is now closed. If we want to change the API, we need to do it in a 2.1. But, I think we need a set policy. That requires discussion here on-list. Hopefully, we can start that now. I believe the answer to this question dictates how soon we open 2.1/3.0. And as a module writer, I'd like to see that API carved in stone for a _long_ time now... It's basically only 3 months that I (in my extreme dumbness of C, I admit) can write an Apache 2.0 module without starting to cry trying to figure out what segfaults (my code or your code)... Before someone will pick up and try out _my_ modules, it'll take _AT_LEAST_ another six months good, and after that, I'd really like to get some vacation and try to get a girlfriend rather than chasing web-servers :) But, we'd also benefit (IMHO) from a meeting face-to-face where a majority of our developers can go to. I'm just curious how many of our developers would *not* attend ApacheCon Las Vegas in November. If we have enough that can't make it, I think it warrants us considering other options for meeting. Perhaps I might be the only one who can't/won't make it. If so, then so be it. -- justin Do it on this side of the pond and I'm game... :) Or another good chance would be Oreilly's Open Source conference in San Diego in late July (just because I'm going to be there) or around that area (CA) around that time. Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
[PATCH] Correct APXS behavior in non-standard layout installations
This patch will fix a couple of problems I found when building modules using APXS when Apache 2.0 is installed not following a custom layout (but a weird one like my DarwinBundle). Pie patch.apxs.txt Description: Binary data
[PATCH] Add libdir entries in config.layout...
We forgot to put libdir in config.layout, it's nice to have it around there as well (looks better when non-standard layouts are used). Pier
[PATCH] Add --includedir to configure.in
This needs to be specified, otherwise headers will go into weird locations when doing a make install... Pier patch.configure.txt Description: Binary data
Re: [PATCH] Add libdir entries in config.layout...
Pier Fumagalli [EMAIL PROTECTED] wrote: We forgot to put libdir in config.layout, it's nice to have it around there as well (looks better when non-standard layouts are used). Shit, sometimes I should click that Add Attachment on my mail client :) Pier patch.layout.txt Description: Binary data
Re: [PATCH] Correct APXS behavior in non-standard layoutinstallations
Pier Fumagalli [EMAIL PROTECTED] wrote: This patch will fix a couple of problems I found when building modules using APXS when Apache 2.0 is installed not following a custom layout (but a weird one like my DarwinBundle). Thom actually showed me his patch posted as Subject: [PATCH] Fix apxs so it is relocatable... Message-ID: 20020401184143.GA9215@eustasy It works great for me on my wicked installation layout, and today we fixed another couple of things left from his patch (a couple of hardcoded build directories were still in, and it wasn't properly resolving the ServerRoot when apxs was called from a symlink)... This is the revised and updated patch... Pier / Thom :) patch.apxs.txt Description: Binary data
Re: httpd.conf no longer installed
Doug MacEachern [EMAIL PROTECTED] wrote: with httpd-2.0-HEAD, installing into a directory where no conf/ already exists, no httpd.conf is installed, only: % ls -1 conf/ highperformance.conf highperformance-std.conf httpd.conf.in httpd-std.conf.in magic mime.types ssl.conf ssl-std.conf problem does not exist with the APACHE_2_0_34 tag. Did you run ./buildconf? Autoconf should generate it now from the httpd-std.conf.in file... Pier
Re: httpd.conf no longer installed
Doug MacEachern [EMAIL PROTECTED] wrote: nope, still isn't there. % uname -a Linux mako.covalent.net 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown % autoconf --version Autoconf version 2.13 % cat config.nice #! /bin/sh # # Created by configure CFLAGS=-Wall -g; export CFLAGS /home/dougm/apache/farm/src/httpd-2.0-cvs/configure \ --prefix=/home/dougm/apache/farm/install/prefork-debug-shared-all-exp \ --with-mpm=prefork \ --srcdir=/home/dougm/apache/farm/src/httpd-2.0-cvs \ --enable-maintainer-mode \ --enable-mods-shared=all \ --enable-modules=all \ --enable-example \ --enable-case_filter \ --enable-case_filter_in \ --enable-cache \ --enable-echo \ --enable-deflate \ --enable-ssl \ --with-ssl=/home/dougm/openssl \ $@ What do your last lines of configure.in look like? And when you run ./configure. what's the output of the last (let's say) 50 lines? Pier
[PATCH] Remove compiled-in directory names from MPM...
There are a bunch of hard-coded logs/... file names in HTTPD's MPM directory (grep logs/ server/mpm/*/*). This patch adds a new header file (ap_config_layout.h), which contains ../configure-specified layout information, and makes all those #define(s) in MPM to inherit default values from what has been specified in ./configure rather than hard coded server-root relative paths... Pier diff.txt Description: application/applefile diff.txt Description: Binary data ap_config_layout.h.in Description: Binary data
Re: [PATCH] Remove compiled-in directory names from MPM...
Whops... Left one extra logs in there... Thanks sander... Pier diff.txt Description: application/applefile diff.txt Description: Binary data
Re: [PATCH] Remove compiled-in directory names from MPM...
Sander Striker [EMAIL PROTECTED] wrote: From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: 03 April 2002 13:09 There are a bunch of hard-coded logs/... file names in HTTPD's MPM directory (grep logs/ server/mpm/*/*). This patch adds a new header file (ap_config_layout.h), which contains .../configure-specified layout information, and makes all those #define(s) in MPM to inherit default values from what has been specified in ./configure rather than hard coded server-root relative paths... +1 for this change. It would be nice to have all the layout specific stuff in one place. Thanks Sander :) BTW, forgot a little apachectl.in patch as well... Index: apachectl.in === RCS file: /home/cvspublic/httpd-2.0/support/apachectl.in,v retrieving revision 1.10 diff -U3 -r1.10 apachectl.in --- apachectl.in13 Mar 2002 20:48:05 - 1.10 +++ apachectl.in3 Apr 2002 11:21:18 - @@ -26,14 +26,14 @@ # # # the path to your PID file -PIDFILE=@prefix@/logs/@progname@.pid +PIDFILE=@exp_runtimedir@/@progname@.pid # # the path to your httpd binary, including options if necessary -HTTPD='@prefix@/bin/@progname@' +HTTPD='@exp_bindir@/@progname@' # # pick up any necessary environment variables -if test -f @prefix@/bin/envvars; then - . @prefix@/bin/envvars +if test -f @exp_bindir@/envvars; then + . @exp_bindir@/envvars fi # # a command that outputs a formatted text version of the HTML at the I'm rebuilding Apache 2.0 with a totally non-standard directory layout (bundle installation on MacOS/X, all paths are screwed up! :), if I catch something else, will let you know... Pier
