Re: Use of X509_NAME_oneline in mod_ssl
On Fri, Oct 15, 2004 at 03:41:59PM -0700, Madhusudan Mathihalli wrote: Well.. for one use I have atleast 2 different customers who map the information retrieved from a client certficate to the LDAP database. Both of them came back with the same question: Does SSL_CLIENT_S_DN conform to any known standard. The one standard I know for representing DN are the 1779 and 2253. Are there any other standards - if so, please let me know for I'm unaware. As far as I'm aware, it's just a convention adopted by OpenSSL. The patch is pretty simple if we want to change mod_ssl to use the RFC supported style. However, there are probably a lot of users who will not be happy if we change it abruptly. Hence I propose that we add a new SSL directive (SSLDNFormat or something like that) which allows the user to configure the format he likes (default will be the non-RFC compliant). Which use of DNs do you want to change? Controlling these disparate uses of DNs from one config directive sounds confusing. Okay - what do you suggest ? Changing just the _DN variable format with a config directive sounds OK. Adding new variables would be an alternative, but the names would probably get *really* ugly... joe
Re: [RFC] Patch for mod_log_config to allow conditioning on status code
On Fri, Oct 15, 2004 at 08:14:03PM -0600, Paul Querna wrote: Glenn Strauss wrote: On Fri, 15 Oct 2004, Luc Pardon wrote: What are the general requirements to getting a patch or module included in the contrib/ directory? And on that topic, what happened to http://www.apache.org/dist/httpd/contrib/ ? I think /contrib/ is dead. I would rather look at committing your patch to httpd CVS. I don't have any objections to it on a concept level, but I have not reviewed your code in detail. Thanks, Paul. I don't want to discourage Luc, but there's a steep uphill battle to getting anything into Apache 1.3. I've tried unsuccessfully in the past to get what amounts to a two-line addition to mod_log_config.c to add vhost information to the error log. Here's some of the history (all for a patch whose meat is 2 lines!): 2003-06-24 http://marc.theaimsgroup.com/?l=apache-httpd-devm=105649710514527w=2 2003-07-08 http://marc.theaimsgroup.com/?l=apache-httpd-devm=105763930020467w=2 2003-09-04 http://marc.theaimsgroup.com/?l=apache-httpd-devm=106268054016100w=2 2003-10-13 http://marc.theaimsgroup.com/?l=apache-httpd-devm=106608066626342w=2 http://marc.theaimsgroup.com/?l=apache-httpd-devm=106609152403979w=2 I have been using the current patch, attached below, in production for a very long time now. Luc, do you think the patch below might have a place in your modifications, possibly wrapped in an #ifdef so that it can be enabled or disabled at compile time? Cheers, Glenn # # http://www.gluelogic.com/code/ # diff -ruN apache_1.3.31/src/main/http_log.c apache_1.3.31-new/src/main/http_log.c --- apache_1.3.31/src/main/http_log.c 2004-02-16 17:29:33.0 -0500 +++ apache_1.3.31-new/src/main/http_log.c 2004-05-24 12:26:06.0 -0400 @@ -349,7 +349,8 @@ * first. -djg */ len += ap_snprintf(errstr + len, sizeof(errstr) - len, - [client %s] , r-connection-remote_ip); + [client %s] [%s:%u] , r-connection-remote_ip, + ap_get_server_name(r), ap_get_server_port(r)); } if (!(level APLOG_NOERRNO) (save_errno != 0)
Re: [RFC] Patch for mod_log_config to allow conditioning on status code
On Sat, 16 Oct 2004, Glenn Strauss wrote: I don't want to discourage Luc, but there's a steep uphill battle to getting anything into Apache 1.3. Of course. Apache 1.3 is an old, legacy application, and vastly less capable than current versions. It's still maintained, but noone is in the business of adding new *features*. 2.1 is where interesting things happen, while 2.0 is intermediate: new features may be added, but stability and binary-compatibility are more important. I might review and incorporate a third-party patch for 2.x, but certainly wouldn't for 1.x unless someone was paying. diff -ruN apache_1.3.31/src/main/http_log.c apache_1.3.31-new/src/main/http_log.c --- apache_1.3.31/src/main/http_log.c 2004-02-16 17:29:33.0 -0500 +++ apache_1.3.31-new/src/main/http_log.c 2004-05-24 12:26:06.0 -0400 Bugzilla is a good place for patches like that. People who want it can help themselves, without compromising stability. -- Nick Kew
RE: [RFC] Patch for mod_log_config to allow conditioning on status code
Of course. Apache 1.3 is an old, legacy application, and vastly less capable than current versions. But millions and millions of users rely on it everyday. What might help migration is a simple chart showcasing the differences between 2.x and 1.x I'm no power user of Apache but I still can't see why Apache 2.x is a MUST HAVE vs. a stable product in use by millions of users. Apache is facing a marketing problem not a technology problem Peter -Original Message- From: Nick Kew [mailto:[EMAIL PROTECTED] Sent: Saturday, October 16, 2004 6:31 AM To: [EMAIL PROTECTED] Subject: Re: [RFC] Patch for mod_log_config to allow conditioning on status code On Sat, 16 Oct 2004, Glenn Strauss wrote: I don't want to discourage Luc, but there's a steep uphill battle to getting anything into Apache 1.3. Of course. Apache 1.3 is an old, legacy application, and vastly less capable than current versions. It's still maintained, but noone is in the business of adding new *features*. 2.1 is where interesting things happen, while 2.0 is intermediate: new features may be added, but stability and binary-compatibility are more important. I might review and incorporate a third-party patch for 2.x, but certainly wouldn't for 1.x unless someone was paying. diff -ruN apache_1.3.31/src/main/http_log.c apache_1.3.31-new/src/main/http_log.c --- apache_1.3.31/src/main/http_log.c 2004-02-16 17:29:33.0 -0500 +++ apache_1.3.31-new/src/main/http_log.c 2004-05-24 12:26:06.0 -0400 Bugzilla is a good place for patches like that. People who want it can help themselves, without compromising stability. -- Nick Kew
[PATCH] Site, ApacheCon 2004
Hi, I did some mods to the site, highlighting all sessions about httpd, but frankly, it looks totally messy. If someone with a bright idea on how to make this look better wants to take a stab at it, that would be much appreciated. Sander site.ac2004.patch Description: Binary data
Re: [PATCH] Site, ApacheCon 2004
On Sat, 16 Oct 2004, Sander Striker wrote: I did some mods to the site, highlighting all sessions about httpd, but frankly, it looks totally messy. If someone with a bright idea on how to make this look better wants to take a stab at it, that would be much appreciated. I table-ized it and I think it's reasonable now. I'll just go ahead and commit it to httpd-site and if anybody wants to tweak it they can do it live. --Cliff
RE: Bug: Apache hangs if script invokes fork/waitpid
-Original Message- From: Rüdiger Plüm [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 2:45 PM To: [EMAIL PROTECTED] Subject: Re: Bug: Apache hangs if script invokes fork/waitpid [..cut..] I think 1. is the problem in our case. If you do a fork in your perl script you simply create another Apache process where your forked perl script is running inside. After the forked part of the script has finished its job mod_perl will be left and the Apache process will continue doing its normal designed work: Waiting for the next request. I would prefer not to call it as designed to work. It seems like this situation was not taken into considertaion in the design. Atleast I don't believe it was designed deliberately so that it would hang. This behaviour should be totally independent from the MPM you use. Yes, ideally it should. I am not sure if it is the case though. So I think mod_perl needs to provide some kind of wrapper for the fork command that does the needed cleanups just before the real fork is done (as other modules in Apache do that fork processes) and that will terminate the process as soon as the user provided perl code of this forked process is left. So the behaviour will differ from the normal mod_perl behaviour (giving control back to the Apache process / thread). It is not a mod_perl specific problem. It is a problem with any module like mod_perl. That is a script executed by this module can invoke fork(). You see it is not appropriate to handle this situation in mod_perl. For the following reasons: - mod_perl doesn't really know that the scipt called mod_perl. It hands off the script to Perl to interpret and execute. So it is Perl who is acutally calling fork()...not mod_perl - This means mod_perl needs to know too much about the Apache's internal working. As to whether it should call pthread_exit() or exit() is dependent on the MPM. - Secondly mod_perl's decision to terminate could be premature it doesn't give apache any chance to perform any clean ups and other things(if needed). - In general the decision to exit a proram should not be buried deep in a function call stack. This decision should be pushde out the highest level possible ... ideally main(). -Roshan
Re: Bug: Apache hangs if script invokes fork/waitpid
Naik, Roshan wrote: -Original Message- From: Rüdiger Plüm [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 2:45 PM To: [EMAIL PROTECTED] Subject: Re: Bug: Apache hangs if script invokes fork/waitpid [..cut..] I think 1. is the problem in our case. If you do a fork in your perl script you simply create another Apache process where your forked perl script is running inside. After the forked part of the script has finished its job mod_perl will be left and the Apache process will continue doing its normal designed work: Waiting for the next request. I would prefer not to call it as designed to work. It seems like this situation was not taken into considertaion in the design. Atleast I don't believe it was designed deliberately so that it would hang. Ok. You are right that for sure it has not been designed to hang. What I mean by works as designed is that the design does not allow user provided code within Apache to do a fork without proper preparation. I would not say that it was not taken into consideration. But I think these are more or less philosophical questions that drive us away from the real problem and a solution for this problem. [...] This behaviour should be totally independent from the MPM you use. Yes, ideally it should. I am not sure if it is the case though. So I think mod_perl needs to provide some kind of wrapper for the fork command that does the needed cleanups just before the real fork is done (as other modules in Apache do that fork processes) and that will terminate the process as soon as the user provided perl code of this forked process is left. So the behaviour will differ from the normal mod_perl behaviour (giving control back to the Apache process / thread). It is not a mod_perl specific problem. It is a problem with any module like mod_perl. That is a script executed by this module can invoke fork(). You are right that any module trying to do a fork and execute code in the forked process will experience the same problem, BUT: Modules should not do a fork or allow code they execute like scripts to do a fork without doing proper pre- and post operations. If they do, it is either a bug of the module or a bug of the script they execute. Do not get me wrong: I admit that may be there should be some additional API functions for a module to prepend a fork and cleanly exit this forked process afterwards. These API function should be usable for the module without having a knowledge of the running MPM. You see it is not appropriate to handle this situation in mod_perl. For the following reasons: - mod_perl doesn't really know that the scipt called mod_perl. It hands off the script to Perl to interpret and execute. So it is Perl who is acutally calling fork()...not mod_perl This is the real problem: mod_perl does not have real control over what the Perl script does once it handed it over to Perl. As Perl allows you to do many things, there are many ways to harm the Apache process used as a container to run the Perl script. So special care must be taken when writing Perl scripts for mod_perl and if you do not think that the script writers are trustable then mod_perl should provide some kind of sandbox for executing the code to prevent such harmful operations. So from the part of the Perl script I see only two approaches: 1. Guidelines for script programmers that clearly state that you have to call a special Perl function for doing a fork inside mod_perl, because otherwise you will shoot yourself. 2. Create some kind of sandbox for the code running inside mod_perl to prevent the code doing harmful things like fork in our case. This may be also useful for other applications to restrict the permissions of a script. mod_perl on the other side should provide a function that allows the Perl script running inside mod_perl to do a fork in a safe way. Therefore it must embed the real fork library / system call into the correct pre and post operational code. Whether this pre and post operational code should receive better support from Apache API functions should be part of the further discussion. As far as I remeber possible approaches like a special mod_fork have already been discussed by Jeff and Paul in this thread. - This means mod_perl needs to know too much about the Apache's internal working. As to whether it should call pthread_exit() or exit() is dependent on the MPM. As said above this should be encapsulated in appropriate API functions that do not require the caller to have any knowledge of the MPM running. - Secondly mod_perl's decision to terminate could be premature it doesn't give apache any chance to perform any clean ups and other things(if needed). Of course mod_perl must do the cleanups by calling the appropriate Apache API functions before terminating the process. [...] Regards Rüdiger
Re: [RFC] Patch for mod_log_config to allow conditioning on status code
For a start I'd like to invite comments on a) the concept and b) the syntax. this sounds interesting in general, although I find myself wondering about a different approach - expanding SetEnvIf to include response-type things (like status, content-type, etc) in addition to request-type things. really, the combination of CustomLog and SetEnvIf should be sufficient for this kind of thing, provided you can access the needed information from the request_rec and populate subprocess_env. indeed you could write a simple log handler of your own that examines r-status and populates r-subprocess_env accordingly, then still allow mod_log_config to do the logging with no patch to core required, but I suppose the point here is to have a way to do this solely from core :) If these are acceptable, I would prepare and submit the patch itself so you can judge the code. in line with the other suggestions in this thread, I would suggest submitting a patch against 2.1 (httpd-2.0 cvs HEAD) following the appropriate style guidelines. I, at least, promise to review it and shepherd it through the process, wherever that may lead it. --Geoff
