Re: related config directives
On Wednesday 26 December 2001 08:10 am, Greg Ames wrote: Ryan Bloom wrote: Since we already know that we need this general ability for some of the auth directives (see John Sterling's posts about some of the problems with AuthType and AuthName), I would much rather have a generic function that will manipulate the tree itself. Swapping things in the config tree breaks if the nodes involved are in different scopes: AuthType basic Directory /docroot/flintstone AuthName Fred /Directory Directory /docroot/rubble AuthName Barney /Directory I think that's a legitimate config. But if we swapped AuthName AuthType, we would destroy it. That shouldn't be a legitimate config IMHO. However, I would suggest that the swap function should only be used to swap things on the same level of the config tree. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: related config directives
On Mon, Dec 24, 2001 at 09:40:03AM -0800, Ryan Bloom wrote: I thought of another reason to do this in the tree itself. The point of the config tree is to keep the current config in memory. If you are going to modify the config, you need to modify it in the tree. By doing to work on the tree, you get that for free. I'm confused (it may just be the eggnog :), but aren't we talking about two different things? There are fatal and non-fatal errors in the config. We want to give a meaningful message when we discover a fatal error, but we just want to issue a warning and try to adjust something sane for non-fatal errors. I can see how fidgeting with absurd settings by rearranging the order in the tree will make it easier to deal with some of the non-fatal errors, but doesn't it seem easiest to deal with the fatal errors all at once after we've got a stable config tree with all the defaults in place in the tree? -aaron
Re: related config directives
On Sunday 23 December 2001 09:38 am, Ryan Bloom wrote: On Sunday 23 December 2001 06:27 am, Jeff Trawick wrote: Greg Ames [EMAIL PROTECTED] writes: ...are more painful to deal with than you might think, if the user is allowed to code them in any order. another thing is that the user can code any number of them, possibly with different values... swapping items in the tree doesn't necessarily deal with that properly while doing stuff in a post-config hook wouldn't run into problems (it could just use the setting from the last time the directive occurred) Yeah, but that can be handled by searching from the end of the list instead of the front. The problem with doing it in post-config is that it isn't generic enough. It will work for any directive that is only allowed in the main server config, but you can't really use it for anything in a different scope. Since we already know that we need this general ability for some of the auth directives (see John Sterling's posts about some of the problems with AuthType and AuthName), I would much rather have a generic function that will manipulate the tree itself. I thought of another reason to do this in the tree itself. The point of the config tree is to keep the current config in memory. If you are going to modify the config, you need to modify it in the tree. By doing to work on the tree, you get that for free. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: related config directives
Greg Ames [EMAIL PROTECTED] writes: ...are more painful to deal with than you might think, if the user is allowed to code them in any order. another thing is that the user can code any number of them, possibly with different values... swapping items in the tree doesn't necessarily deal with that properly while doing stuff in a post-config hook wouldn't run into problems (it could just use the setting from the last time the directive occurred) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: related config directives
On Sunday 23 December 2001 06:27 am, Jeff Trawick wrote: Greg Ames [EMAIL PROTECTED] writes: ...are more painful to deal with than you might think, if the user is allowed to code them in any order. another thing is that the user can code any number of them, possibly with different values... swapping items in the tree doesn't necessarily deal with that properly while doing stuff in a post-config hook wouldn't run into problems (it could just use the setting from the last time the directive occurred) Yeah, but that can be handled by searching from the end of the list instead of the front. The problem with doing it in post-config is that it isn't generic enough. It will work for any directive that is only allowed in the main server config, but you can't really use it for anything in a different scope. Since we already know that we need this general ability for some of the auth directives (see John Sterling's posts about some of the problems with AuthType and AuthName), I would much rather have a generic function that will manipulate the tree itself. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: related config directives
On Thu, Dec 20, 2001 at 03:22:33PM -0500, Greg Ames wrote:
...are more painful to deal with than you might think, if the user is
allowed to code them in any order.
I'd like the comparisons between MaxClients and ServerLimit and the
equivalent thread directives to be coding order insensitive. So I
created a post-config hook to do the comparing adjusting. The code
was very simple, but the log messages went to the error log file twice,
rather than to the console once which is what people are accustomed to
for config errors.
worker already has the same situation with MaxClients and
ThreadsPerChild. It has a clever but kind of scary solution: a
pre-config hook which swaps nodes in the config tree if it doesn't like
the order. Then the comparisons, adjusting, and logging are done when
the second directive is parsed.
While I think it's a very cool hack, mucking with the innards of the
config tree bothers me some. config.c could provide an API to do order
checking and swapping, but I can't see this as a general solution.
Think about cases where one directive is in container X and the other
isn't - yuck!
I agree (and I'm the one who wrote it).
What if the very first ap_run_post_config hook was moved to before the
logs files were opened? Then we could have simple logic to compare or
otherwise process multiple directives. Any error messages would go
directly to the console. If you wanted them to also go to the error log
file, that would just happen during the second post-config call; if you
don't want that, it's easy to avoid.
I was thinking the same thing. My only concern was that something has
already been written that assumes post_config already has the log opened
and stderr redirected. Unless that is a problem or someone else can
come up with another reason not to do this, I'm +1.
Another possibility that would avoid the whole issue altogether would
be to simply add another hook before open_logs. I started doing this
yesterday on the plane:
Index: server/main.c
===
RCS file: /home/cvs/httpd-2.0/server/main.c,v
retrieving revision 1.111
diff -u -u -r1.111 main.c
--- server/main.c 2001/12/18 20:26:15 1.111
+++ server/main.c 2001/12/20 20:31:52
@@ -412,6 +412,10 @@
destroy_and_exit_process(process, 0);
}
apr_pool_clear(plog);
+if ( ap_run_validate_config(pconf, plog, ptemp, server_conf) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR| APLOG_NOERRNO, 0, NULL,
+Unable to validate the config\n);
+destroy_and_exit_process(process, 1);
+}
if ( ap_run_open_logs(pconf, plog, ptemp, server_conf) != OK) {
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR| APLOG_NOERRNO, 0, NULL,
Unable to open logs\n);
destroy_and_exit_process(process, 1);
Index: include/http_config.h
===
RCS file: /home/cvs/httpd-2.0/include/http_config.h,v
retrieving revision 1.92
diff -u -u -r1.92 http_config.h
--- include/http_config.h 2001/11/24 00:08:29 1.92
+++ include/http_config.h 2001/12/20 20:31:55
@@ -974,6 +974,18 @@
AP_DECLARE_HOOK(void,pre_config,(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t
*ptemp))
/**
+ * Run the validate_config function for each module. This function should
+ * validate the config parameters accepted by the module, and return
+ * OK or non-OK to signify success.
+ * @param pconf The config pool
+ * @param plog The logging streams pool
+ * @param ptemp The temporary pool
+ * @param s The list of server_recs
+ * @return OK or DECLINED on success anything else is a error
+ */
+AP_DECLARE_HOOK(int,validate_config,(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t
+*ptemp,server_rec *s))
+
+/**
* Run the post_config function for each module
* @param pconf The config pool
* @param plog The logging streams pool
-aaron
Re: related config directives
On Thursday 20 December 2001 12:22 pm, Greg Ames wrote: ...are more painful to deal with than you might think, if the user is allowed to code them in any order. I'd like the comparisons between MaxClients and ServerLimit and the equivalent thread directives to be coding order insensitive. So I created a post-config hook to do the comparing adjusting. The code was very simple, but the log messages went to the error log file twice, rather than to the console once which is what people are accustomed to for config errors. worker already has the same situation with MaxClients and ThreadsPerChild. It has a clever but kind of scary solution: a pre-config hook which swaps nodes in the config tree if it doesn't like the order. Then the comparisons, adjusting, and logging are done when the second directive is parsed. While I think it's a very cool hack, mucking with the innards of the config tree bothers me some. config.c could provide an API to do order checking and swapping, but I can't see this as a general solution. Think about cases where one directive is in container X and the other isn't - yuck! This is the point of the config tree, it allows you to modify the config before we actually run the configuration, so that you can find these dependancies and fix them quickly. Putting the logic in the directive handlers doesn't really work, because you still have an order dependancy. Think of it this way, these are good configs: MaxClients 500 ServerLimit 525 ServerLimit 20 MaxClients 5 This is a bad config: MaxClients 525 ServerLimit 500 Where do you catch it though? In ServerLimit, then you will also catch the second good config above, which is a good config If you try to catch it in MaxClients, you will catch the first config above, which is a good config. The only solution is to choose default values that are invalid, so that you can make sure that you always check in the last directive handler, but that is incredibly ugly. We can easily create a function to do the swapping, which is more generic, but the swapping is the only 100% correct way to do this. Ryan I'm inclined to agree with Ryan. Let's just make a function to do the swapping. Bill
Re: related config directives
On Thursday 20 December 2001 01:01 pm, Bill Stoddard wrote: On Thursday 20 December 2001 12:22 pm, Greg Ames wrote: ...are more painful to deal with than you might think, if the user is allowed to code them in any order. I'd like the comparisons between MaxClients and ServerLimit and the equivalent thread directives to be coding order insensitive. So I created a post-config hook to do the comparing adjusting. The code was very simple, but the log messages went to the error log file twice, rather than to the console once which is what people are accustomed to for config errors. worker already has the same situation with MaxClients and ThreadsPerChild. It has a clever but kind of scary solution: a pre-config hook which swaps nodes in the config tree if it doesn't like the order. Then the comparisons, adjusting, and logging are done when the second directive is parsed. While I think it's a very cool hack, mucking with the innards of the config tree bothers me some. config.c could provide an API to do order checking and swapping, but I can't see this as a general solution. Think about cases where one directive is in container X and the other isn't - yuck! This is the point of the config tree, it allows you to modify the config before we actually run the configuration, so that you can find these dependancies and fix them quickly. Putting the logic in the directive handlers doesn't really work, because you still have an order dependancy. Think of it this way, these are good configs: MaxClients 500 ServerLimit 525 ServerLimit 20 MaxClients 5 This is a bad config: MaxClients 525 ServerLimit 500 Where do you catch it though? In ServerLimit, then you will also catch the second good config above, which is a good config If you try to catch it in MaxClients, you will catch the first config above, which is a good config. The only solution is to choose default values that are invalid, so that you can make sure that you always check in the last directive handler, but that is incredibly ugly. We can easily create a function to do the swapping, which is more generic, but the swapping is the only 100% correct way to do this. Ryan I'm inclined to agree with Ryan. Let's just make a function to do the swapping. I meant to mention that if you really want to fix this problem, we should move to an XML based config language. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: related config directives
Ryan Bloom [EMAIL PROTECTED] writes: I'm inclined to agree with Ryan. Let's just make a function to do the swapping. I had the same opinion... a swap function owned by the config tree code. I meant to mention that if you really want to fix this problem, we should move to an XML based config language. First awk, now XML. !*^%$%$## (just kidding; XML and related tools are worth being comfortable with) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
