Re: svn commit: r1896976 - /httpd/httpd/branches/2.4.x/STATUS
On Mon, Jan 17, 2022 at 02:16:32PM +0100, Ruediger Pluem wrote: > > > On 1/17/22 1:38 PM, Eric Covener wrote: > > On Mon, Jan 17, 2022 at 7:28 AM Ruediger Pluem wrote: > >> > >> > >> > >> On 1/16/22 10:35 PM, William A Rowe Jr wrote: > >>> 4 day ago, you all saw this. 6 years ago, you all started using this on > >>> trunk. > >>> > >>> Don't know what I can to do help this along and honor the library > >>> author's wishes for > >>> all of us to walk away from the dead fork, and use the maintained > >>> fork. It's whatever > >>> it is, I'm out of here and removing the backport application branch, > >>> whoever 3rd upvotes > >>> this be prepared to apply this for us all, thanks. > >> > >> With regards to the de-optimization / stack usage probably stupid question: > >> Can't we use the TLS features that several compilers offer? > >> e.g. see at the end of the page at > >> https://stackoverflow.com/questions/18298280/how-to-declare-a-variable-as-thread-local-portably > >> > >> If we have no thread_local we could fall back to the current unoptimized > >> implementation? > > > > I more identified with Joe's comment, if we had an _ex version we > > could pass pools for our own usage. > > If some other heavy regex hitter third-party module finds an issue > > (like mod_security) it might degrade a little bit but they can always > > take advantage of it too. > > > > Also, what about alloca()? > > > > Trivia but I should add that in an integration between two third-party > > mods I recently ripped out apr_threadkey stuff due to a crash after > > some OS updates that nobody can explain. Fortunately the problematic > > API had been extended with userdata and it was no longer absolutely > > necessary. It was our only use of these API's so I was glad to > > simplify and just remove them and move on. > > Net, I would be hesitant to introduce something too new. > > From a quick glance apr_threadkey seems to use pthread_*specific for which I > found postings that state that it is slow compared to > the compiler implemented thread locals. OTOH __thread alike stuff does not > seem to offer any cleanup at thread exit which would > not allow us to free any resource that was created for that thread :-(. Hence > I guess providing a pool to the call remains the > only solution here. Maybe use thread-local storage to set a pointer to an apr_pool associated with the thread, and set that only for short-lived (or otherwise appropriately scoped) threads? Cheers, Glenn
Re: New Module: mod_auth_mysql_digest
torsdagen den 7 november 2002 01.19 skrev Greg Stein: On Mon, Nov 04, 2002 at 07:21:32AM -0500, Jeff Trawick wrote: Justin Erenkrantz [EMAIL PROTECTED] writes: --On Friday, November 01, 2002 16:02:45 -0800 Rob Emanuele [EMAIL PROTECTED] wrote: So I took the mod_auth_digest code and munged it to use mysql for authentication. Swell. It works great and we're heavily using it. If you'd be willing to write this as an auth provider, I'm sure we might be interested in integrating it in our tree. -- justin absolutely +1 here, too. Considering the popularity of MySQL-based auth, I think this would be a great addition to httpd. See: http://www.securityspace.com/s_survey/data/man.200210/apachemods.html Cool, no one's cooking up a mod_log_mysql for apache2? http://modules.apache.org/ http://modules.apache.org/search and do a search for mod Or do a search for mysql Fun place to look around. -Glenn
Re: [VOTE] Location of aaa rewrite
Please vote: [X] Check in aaa rewrite to 2.0. [ ] Check in aaa rewrite to 2.1. Adoption of Apache 2 so far has been low enough that Apache 2 may still be considered to be in the early adopter phase. Breaking compatibility is to be avoided when possible, but is allowable when necessary, and the aaa rewrite is necessary. Hopefully, early adopters read release notes. :-) -Glenn
Re: 2.0.40 (UNIX), mysterious SSL connections to self
On Thu, Aug 29, 2002 at 09:21:27PM -0400, Jeff Trawick wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Looking into the matter, I discovered that this error is logged whenever a connection from localhost to localhost:443 is made. The errors ALWAYS occur after apachectl startssl; they never occur with apachectl start. I'd bet that this is idle server maintenance (taking down a child process which isn't necessary). The non-SSL path doesn't log an error for a dummy connect but evidently the SSL path does. The connect to itself isn't a bug, though it would be nice to avoid the SSL complaints. Try swapping the order of your listen statements to see if that gets rid of the complaints (i.e., if the dummy connect to wake up a child is then done to the non-SSL socket). My solution to the complaints was to use piped error logs and have a simple Perl script as the first script in a pipeline. The Perl script's only job was to remove those error messages and then pass the log line on to cronolog. The reason for taking such a measure was because the server farm was behind a pair of commercial load balancers which made TCP connections to port 80 and port 443 ** every second ** to health check that the servers were alive and accepting connections within a reasonable response time. Then, it shut down the connection, without attempting any SSL negotiation. So every second, every server was logging two SSL failure messages (from each of the redundant load balancers). Talk about noise in the logs! It would be Real Nice (tm) if these sort of SSL error messages weren't reported unless some sort of data was exchanged above the connection level. Only in those cases would the SSL error message be correct that SSL negotiation failed, as opposed to not even having started. -Glenn
Re: daedalus is running httpd-2.0.pre40
On Tue, Jul 23, 2002 at 11:03:03AM -0400, Greg Ames wrote: johannes m. richter wrote: If you read this whole thread, you'll see that I'm not the only one who likes having current -std.conf files available. They worked this way for ages. I don't recall seeing any complaints about this behavior until yesterday. .. People seem to want their conf-directories to be really clean - which is can understand. But i also understand it might be useful to have a current default configuration file around. IMHO the documentation dir SERVERROOT/manual/conf/ perhaps?) would be a good place for this. SERVERROOT/manual/conf-default/ ? That might make it clearer that this is just for the default configs. Opinions? As another lurker on the list, I'd like to weigh in on having the template conf files in conf/sample and named after the release which created it, i.e. conf/sample/httpd.conf-2.0.40 (You could also use conf/dist/* or conf/template/* or ...) This avoids cluttering conf and keeps the template configs close at hand for reference. Apache conf files are large and they tend to change subtly between releases. It is really nice to be able to compare differences. Personally, I use the default conf files and comment out what I don't want and comment in my changes explaining the deviation from the distributed defaults. -Glenn
Re: suexec ScritpAlias/ScriptAliasMatch
I am just starting to look at the server code and have been playing with the suexec code. Want to try to pass additional parameters to suexec, in paticular the value of the ScriptAlias or ScriptAliasMatch (after regex) for the VirtualHost. Believe I have found where suexec is called but unable to figure out where the ScriptAlias/Match value is or how to pass it. Any help greatly appreciated. Why modify the httpd code? Why not just (carefully) modify the suEXEC code? suEXEC requires that Apache chdir into the directory with the target script before starting suEXEC. Therefore, getcwd() will return the absolute path equivalent to ScriptAlias or ScriptAliasMatch. (They'll be identical if there are no symlinks in the path.) Anyway, what are you planning on doing with the ScriptAlias or ScriptAliasMatch value in suEXEC? BTW, if you want a quick way to pass additional params to suEXEC, you could use SetEnv in Apache. Then, suEXEC would have the value available to it until the part of suEXEC near the end of the code which purges the environment of all but known good CGI vars. Of course, you should never blindly trust environment values. Same thing with params passed to an suid program such as suEXEC. That's why you should have a really, really good reason for needing to pass additional params to suEXEC. The current parameters (target uid, target gid, and target program) are all rigorously checked by suEXEC before being used. If you plan on using any new info from the environment or from an additional param, then make sure it is properly validated before you use it! -Glenn
Q: licensing suEXEC modifications under GPL?
Hi. I sent this over three weeks ago to the human response email address at apache.org (and pinged them again a week ago), but have yet to receive a response. Would someone on his list please direct me to whom I should contact? A synopsis is that I am requesting that Apache release suEXEC under the GPL. Notwithstanding your opinions on licensing in general, I hope that you'll agree that there are large benefits to releasing *security* software under the GPL. Thank you. Glenn Strauss --- Greetings. suEXEC is a program that I know well, love, and use on numerous servers. Thank you very much! To extend its usage, I have largely rewritten it and am in the process of unit testing. Among many other things, I have modularized it and have added an option (off by default) for suEXEC to safely run in a group environment (with group write privileges). I would like to make my heavily modified version available under the GNU Public License and am writing to ask for permission and advice. (I am not a lawyer and the gnu.org website indicates that the Apache Software License v1.1 is not compatible with the GPL, but does not give specific reasons.) I am hoping that the ASF will consider the merits of suEXEC as a standalone program that may be used with other webservers and will consider releasing suEXEC under the GPL. I have searched through the newsgroup at http://www.apachelabs.org/ and have turned up a number of (not-so-friendly) discussions relating to licensing (GPL, PHP, GZIP, PCRE, ...), so I have an idea where the ASF stands on this issue, but I am asking anyway. Please direct me to where I might find more information on: a) what steps I might take to release my modifications under the GPL with proper attribution to the Apache Software Foundation. b) if the Apache Software Foundation would specifically release suEXEC under the GPL or another GPL compatible license. It is a standalone program and so this would not affect anything else licensed under the Apache Software License. c) other suggestions Your assistance is greatly appreciated. Thank you. Glenn Strauss PS: Yes, I have read: http://www.apache.org/foundation/preFAQ.html#licence The FAQ answer contains a mistake: there is no section 6 in the Apache Software License v1.1 * You have questions about the Apache licence. If you have sent mail about a licence issue or question, please review the online licence at the URL listed below. The gist of the licence is that you may use, modify, and/or [re]distribute the Apache software as-is. As long as you do not change the software, you may re-distribute it and call it Apache. If you alter the software in any way, other than tailoring the configuration files or making it compilable on your platform, you may only refer to it as being based upon Apache. In all cases, altered or not, you must include attribution as described in sections 3 and 6 of the licence. Let us know if you have further questions.
