Re: [VOTE] access control for dynamic hosts
Hello Yann, I guess this question is for me, not the doc :) Yep! [...] So, finally, mentioning that *any* ip/host-based authz should be combined with other authz/authn (SSL certificates, credentials schemes, ...) for stronger requirements may be the way to go. I agree that combining authz is the way to go, esp. with sensitive applications which are more and more hosted outside of organizations, or even provided as SaaS. I'm not sure of a good place to discuss authorization policies in general in the documentation though. Or maybe simply not change the doc since all this might be quite obvious... I would be fine with this solution:-) -- Fabien.
Re: [VOTE] access control for dynamic hosts
Hello Yann, ylavic: I would have liked more (doc) emphasis on the lower security of "Require forward-dns" vs "Require host"'s double DNS lookup How about adding something like: From a security perspective, getting access to a protected page is somehow easier with "forward-dns" because the attacker needs only to control the DNS for the domain, while they would also need to control the reverse DNS with "host". Now, if you have important confidential data, they would not be only protected by host-based authorizations, would they? -- Fabien.
Re: Plan for T of 2.4.19
Hello Yann, https://svn.apache.org/viewvc?view=revision=1734412 Sounds reasonable, would you add an entry in the STATUS file (at the root of branches/2.4.x) to start the vote (with your own)? Ok. I did that as r1735616. -- Fabien.
Re: Plan for T of 2.4.19
Hello Jim, I hope to T 2.4.19 on Mon/Tues with a release on Friday. There are some backports proposed that would be nice to get into this release, I would like to suggest backporting: https://svn.apache.org/viewvc?view=revision=1734412 It is a minor but I think useful feature which does not disrupt much the code base, just add a function and a new authorization provider. Now I'm not sure of the update policy on "bug fix" release, maybe adding a feature is too much, in which case apply the policy and do not backport:-) -- Fabien.
Re: [VOTE] access control for dynamic hosts
Currently 2 votes: +1: Mario Brandt, Yann Ylavic I think you can go ahead, trunk is in CTR (Commit Then Review) mode. I just committed the changes as r1734412: https://svn.apache.org/viewvc?view=revision=1734412 -- Fabien.
Re: [VOTE] access control for dynamic hosts
Hello Yann, +1: Mario Brandt, Yann Ylavic I think you can go ahead, trunk is in CTR (Commit Then Review) mode. Ok, I'll do a last check and commit soon. -- Fabien.
Re: [VOTE] access control for dynamic hosts
I'm proposing to commit the patch if I'm given a go. Currently 2 votes: +1: Mario Brandt, Yann Ylavic -- Fabien.
Re: access control for dynamic hosts (vote?)
Attached is a patch against the sources, including a documentation, which use
the syntax "Require forward-dns foo.apache.org".
Here is a v2 which adds a missing "/" in the XML documentation.
--
Fabien.Index: docs/log-message-tags/next-number
===
--- docs/log-message-tags/next-number (revision 1733791)
+++ docs/log-message-tags/next-number (working copy)
@@ -1 +1 @@
-3354
+3357
Index: docs/manual/mod/mod_authz_host.xml
===
--- docs/manual/mod/mod_authz_host.xml (revision 1733791)
+++ docs/manual/mod/mod_authz_host.xml (working copy)
@@ -58,7 +58,8 @@
Apache's Require
directive is used during the authorization phase to ensure that a user is allowed or
denied access to a resource. mod_authz_host extends the
-authorization types with ip, host and local.
+authorization types with ip, host,
+forward-dns and local.
Other authorization types may also be
used but may require that additional authorization modules be loaded.
@@ -157,6 +158,29 @@
+Require forward-dns
+
+The forward-dns provider allows access to the server
+to be controlled based on simple host names. When
+Require forward-dns host-name is specified,
+all IP addresses corresponding to host-name
+are allowed access.
+
+In contrast to the host provider, this provider does not
+rely on reverse DNS lookups: it simply queries the DNS for the host name
+and allows a client if its IP matches. As a consequence, it will only
+work with host names, not domain names. However, as the reverse DNS is
+not used, it will work with clients which use a dynamic DNS service.
+
+
+Require forward-dns bla.example.org
+
+
+A client the IP of which is resolved from the name
+bla.example.org will be granted access.
+
+
+
Require local
The local provider allows access to the server if any
Index: modules/aaa/mod_authz_host.c
===
--- modules/aaa/mod_authz_host.c (revision 1733791)
+++ modules/aaa/mod_authz_host.c (working copy)
@@ -216,6 +216,71 @@
return AUTHZ_DENIED;
}
+static authz_status
+forward_dns_check_authorization(request_rec *r,
+const char *require_line,
+const void *parsed_require_line)
+{
+const char *err = NULL;
+const ap_expr_info_t *expr = parsed_require_line;
+const char *require, *t;
+char *w;
+
+/* the require line is an expression, which is evaluated now. */
+require = ap_expr_str_exec(r, expr, );
+if (err) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(03354)
+"Can't evaluate require expression: %s", err);
+ return AUTHZ_DENIED;
+}
+
+/* tokenize expected list of names */
+t = require;
+while ((w = ap_getword_conf(r->pool, )) && w[0]) {
+
+apr_sockaddr_t *sa;
+apr_status_t rv;
+char *hash_ptr;
+
+/* stop on apache configuration file comments */
+if ((hash_ptr = ap_strchr(w, '#'))) {
+if (hash_ptr == w) {
+break;
+}
+*hash_ptr = '\0';
+}
+
+/* does the client ip match one of the names? */
+rv = apr_sockaddr_info_get(, w, APR_UNSPEC, 0, 0, r->pool);
+if (rv == APR_SUCCESS) {
+
+while (sa) {
+int match = apr_sockaddr_equal(sa, r->useragent_addr);
+
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(03355)
+ "access check for %s as '%s': %s",
+ r->useragent_ip, w, match? "yes": "no");
+if (match) {
+return AUTHZ_GRANTED;
+}
+
+sa = sa->next;
+}
+}
+else {
+ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, APLOGNO(03356)
+ "No sockaddr info for \"%s\"", w);
+}
+
+/* stop processing, we are in a comment */
+if (hash_ptr) {
+break;
+}
+}
+
+return AUTHZ_DENIED;
+}
+
static authz_status local_check_authorization(request_rec *r,
const char *require_line,
const void *parsed_require_line)
@@ -265,6 +330,12 @@
_parse_config,
};
+static const authz_provider authz_forward_dns_provider =
+{
+_dns_check_authorization,
+_parse_config,
+};
+
static const authz_provider authz_local_provider =
{
_check_authorization,
@@ -309,6 +380,10 @@
ap_register_auth_provider(p, AUTHZ_PROVIDER_GROUP, "host",
AUTHZ_PROVIDER_VERSION,
_host_provider, AP_AUTH_INTERNAL_PER_CONF);
+ap_register_auth_provider(p, AUTHZ_PROVIDER_GROUP, "forward-dns",
+
Re: access control for dynamic hosts (vote?)
Hello Apache developers,
Unfortunately I think you need to pick an awkward name here so it
cannot be confused/misused. Like "forward-dns"
Attached is a patch against the sources, including a documentation,
which use the syntax "Require forward-dns foo.apache.org".
The second file is the same extension as an external module, for easy
testing. The only difference with the integrated version is the error
messages text which are given the function name instead of en APLOGNO, and
the absence of documentation.
I'm proposing to commit the patch if I'm given a go.
Vote?
--
Fabien.Index: docs/log-message-tags/next-number
===
--- docs/log-message-tags/next-number (revision 1733559)
+++ docs/log-message-tags/next-number (working copy)
@@ -1 +1 @@
-3354
+3357
Index: docs/manual/mod/mod_authz_host.xml
===
--- docs/manual/mod/mod_authz_host.xml (revision 1733559)
+++ docs/manual/mod/mod_authz_host.xml (working copy)
@@ -58,7 +58,8 @@
Apache's Require
directive is used during the authorization phase to ensure that a user is allowed or
denied access to a resource. mod_authz_host extends the
-authorization types with ip, host and local.
+authorization types with ip, host,
+forward-dns and local.
Other authorization types may also be
used but may require that additional authorization modules be loaded.
@@ -157,6 +158,29 @@
+Require forward-dns
+
+The forward-dns provider allows access to the server
+to be controlled based on simple host names. When
+Require forward-dns host-name is specified,
+all IP addresses corresponding to host-name
+are allowed access.
+
+In contrast to the host provider, this provider does not
+rely on reverse DNS lookups: it simply queries the DNS for the host name
+and allows a client if its IP matches. As a consequence, it will only
+work with host names, not domain names. However, as the reverse DNS is
+not used, it will work with clients which use a dynamic DNS service.
+
+
+Require forward-dns bla.example.org
+
+
+A client the IP of which is resolved from the name
+bla.example.org will be granted access.
+
+
+
Require local
The local provider allows access to the server if any
Index: modules/aaa/mod_authz_host.c
===
--- modules/aaa/mod_authz_host.c (revision 1733559)
+++ modules/aaa/mod_authz_host.c (working copy)
@@ -216,6 +216,71 @@
return AUTHZ_DENIED;
}
+static authz_status
+forward_dns_check_authorization(request_rec *r,
+const char *require_line,
+const void *parsed_require_line)
+{
+const char *err = NULL;
+const ap_expr_info_t *expr = parsed_require_line;
+const char *require, *t;
+char *w;
+
+/* the require line is an expression, which is evaluated now. */
+require = ap_expr_str_exec(r, expr, );
+if (err) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(03354)
+"Can't evaluate require expression: %s", err);
+ return AUTHZ_DENIED;
+}
+
+/* tokenize expected list of names */
+t = require;
+while ((w = ap_getword_conf(r->pool, )) && w[0]) {
+
+apr_sockaddr_t *sa;
+apr_status_t rv;
+char *hash_ptr;
+
+/* stop on apache configuration file comments */
+if ((hash_ptr = ap_strchr(w, '#'))) {
+if (hash_ptr == w) {
+break;
+}
+*hash_ptr = '\0';
+}
+
+/* does the client ip match one of the names? */
+rv = apr_sockaddr_info_get(, w, APR_UNSPEC, 0, 0, r->pool);
+if (rv == APR_SUCCESS) {
+
+while (sa) {
+int match = apr_sockaddr_equal(sa, r->useragent_addr);
+
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(03355)
+ "access check for %s as '%s': %s",
+ r->useragent_ip, w, match? "yes": "no");
+if (match) {
+return AUTHZ_GRANTED;
+}
+
+sa = sa->next;
+}
+}
+else {
+ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, APLOGNO(03356)
+ "No sockaddr info for \"%s\"", w);
+}
+
+/* stop processing, we are in a comment */
+if (hash_ptr) {
+break;
+}
+}
+
+return AUTHZ_DENIED;
+}
+
static authz_status local_check_authorization(request_rec *r,
const char *require_line,
const void *parsed_require_line)
@@ -265,6 +330,12 @@
_parse_config,
};
+static const authz_provider authz_forward_dns_provider =
+{
+_dns_check_authorization,
+
RE: access control for dynamic hosts
Hello Rick, Forward doesn’t mean dynamic, however, and using one particular solution like that is misleading, IMO. Using “forward-dns” makes more sense to me. Yep, with such a name what it does is pretty clear. That said, how would you intend to handle multiple A records for the same name: look them all up and store in a table, or support only one A record per name? At a minimum, I think that needs to be clearly documented. Sure. The "poc" implementation posted up-thread walks over all the records till a match is found, or this is a deny. There is no attempt at caching anything, as the actual use case is to deal with dynamic dns hosts, so with pretty short refresh times. Caching is the problem of the dns resolver. -- Fabien.
Re: access control for dynamic hosts
Hello Yann, [...] Looks good to me. It would have to be documented though, especially the difference with "Require host" and maybe their complementarity (wrt security). Sure, it needs a documentation, obviously. I will not commit anything without a doc. How about "Require dns" (and mod_authz_dns) for the name? Hmm. Note that "Require host" also uses the DNS, doubly so. I'm not sure that naming one "dns" might not suggest that the other ones would not use it? I think that "Require host" should really be name "Require domain" because it is what it does, then "Require host" would be available... but this is too late:-) Maybe "Require ip" could be extended instead of using a new name: "Require ip myserver.apache.org" Would query the DNS to get the IP when checking for the authorization. Not sure that it is a good idea, though. -- Fabien.
Re: access control for dynamic hosts
How about "Require dns" (and mod_authz_dns) for the name? I think it is reasonable to extend authz_host to disable the reverse check when requested (via some new first arg to require) Note that the inner working logic is different, but this is an implementation detail. What syntax would be appropriate? Require forward host foo.apache.org Require host forward-only foo.apache.org Or maybe just a tag in front of the names? Require host mydomain.org !mydynahost.domain.org Require host mydomain.org *mydynahost.domain.org Require host mydomain.org ?mydynahost.domain.org ??? -- Fabien.
Re: access control for dynamic hosts
This feature makes sense because it allows to allow a full domain, say "apache.org", any host of which the inverse dns resolves to the domain can then be allowed. But this also means that if the reverse dns is not controlled, say with the dynamic dns and a moving ip, ip control does not work, hence my proposal for a lesser version which just checks that a client ip is allowed just by resolving a name. that is unsafe it takes me exactly 5 seconds to add a PTR "myserver.apache.org" to one of our public ip-addresses if i would like to and nobody can do anything against it except check if the A record matchs because that can only be controlled by the domain owner Indeed, but then "host" also checks that forward resolution works, that is "myserver.apache.org" must *also* point back to the same IP. the same for anybody else who has a /24 or bigger network and the reverse dns delegated to his own namservers - i would not do such things, others would and so it's nothing to hand authentication on it Sure, the second forward checks that all is well. The feature I'm proposing is not related to that. I'm suggesting to have a way to specify host names *only* which are checked forward *only*. Require xxx foo.apache.org # allows ip of "foo.apache.org", just be resolving the name For use with dyndns services. -- Fabien.
Re: access control for dynamic hosts
Hello, Maybe the reverse dns is working on your test address? I checked it and yes it does work that way. I never knew it did. Indeed. This feature makes sense because it allows to allow a full domain, say "apache.org", any host of which the inverse dns resolves to the domain can then be allowed. But this also means that if the reverse dns is not controlled, say with the dynamic dns and a moving ip, ip control does not work, hence my proposal for a lesser version which just checks that a client ip is allowed just by resolving a name. -- Fabien.
Re: access control for dynamic hosts
Hello Apache devs, Would anyone have an opinion, please? Although I can just commit the proposed changes, a formal go would be nice. On Sun, 20 Dec 2015, Fabien wrote: Date: Sun, 20 Dec 2015 09:44:55 +0100 (CET) From: Fabien <fab...@apache.org> Reply-To: dev@httpd.apache.org To: APACHE development mailing list <dev@httpd.apache.org> Subject: access control for dynamic hosts Hello folks, I have a simple access control use case for which I have not found a clean solution. I want to control access to a service based on the name of the client, however the client is a dynamic host, which implies that: (1) I do not have any control about the reverse DNS => this rules out "Require host" (2) the IP may change arbitrarily => this rules out "Require ip" By browsing around it seems that I'm not alone having this issue, and I have not found any solution for that with apache configuration, nor a matching module in "modules.apache.org" listing. The current workaround is to update the IP manually when it fails. Although I could automate (say query the ip periodically and update & reload the conf if there is a change), ISTM that it really belongs to apache configuration. I would like something like "Require XXX foo.dynamic-dns.somewhere" (where XXX could be "name", "hostname", "dynamic", ...) which would query the NS when the HTTP request is received and check that the corresponding ip is the client IP. I'm planing to develop a small module for that, and as it is somehow quite a basic service it could be a candidate for being added to "modules/aaa/mod_authz_host.c". Another approach could be to extend apache expressions with a function to query the DNS, but that seems a little overkill. Any thoughts? -- Fabien.
Re: access control for dynamic hosts
Hello Mario, doesn't it work using Require host with a dyndns name? From the documentation about "Require host ...": "It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed." So the reverse DNS must work. A benefit is that it allows to check for a full domain. Note that the source code seems to say the same, although in C:-) At least my test was successful. I'm surprised. I just tested it again from my home (which use a dynamic dns), and it did not work with "Require host" in a context, with "Require host NNN": sh> netcat 3128 GET http://www.google.fr/ HTTP/1.0 HTTP/1.1 403 Forbidden ... So the client was not authorized, but after a reload with a "Require name NNN" from the submitted module: sh> netcat 3128 GET http://www.google.fr/ HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 14 Jan 2016 21:30:40 GMT Server: gws ... Maybe the reverse dns is working on your test address? -- Fabien.
Re: access control for dynamic hosts
Hello folks,
I would like something like "Require XXX foo.dynamic-dns.somewhere"
(where XXX could be "name", "hostname", "dynamic", ...) which would
query the NS when the HTTP request is received and check that the
corresponding ip is the client IP.
I'm planing to develop a small module for that, and as it is somehow
quite a basic service it could be a candidate for being added to
"modules/aaa/mod_authz_host.c".
Attached is a working version with the syntax "Requite name
foo.somewhere".
Note sure whether "name" is the best... name for the authorization
provider, though.
I could append this to mod_authz_host.c & update the documentation if I'm
given a go.
--
Fabien/* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/*
* Security options etc.
*
* Module derived from code originally written by Rob McCool
*
*/
#include "apr_strings.h"
#include "apr_network_io.h"
#include "apr_md5.h"
#include "apr_hash.h"
#define APR_WANT_STRFUNC
#define APR_WANT_BYTEFUNC
#include "apr_want.h"
#include "ap_config.h"
#include "ap_provider.h"
#include "httpd.h"
#include "http_core.h"
#include "http_config.h"
#include "http_log.h"
#include "http_protocol.h"
#include "http_request.h"
#include "mod_auth.h"
#if APR_HAVE_NETINET_IN_H
#include
#endif
static authz_status name_check_authorization(request_rec *r,
const char *require_line,
const void *parsed_require_line)
{
const char *err = NULL;
const ap_expr_info_t *expr = parsed_require_line;
const char *require, *t;
char *w;
/* the require line is an expression, which is evaluated now. */
require = ap_expr_str_exec(r, expr, );
if (err) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, // APLOGNO(FIXME)
"name_check_authorization: "
"Can't evaluate require expression: %s", err);
return AUTHZ_DENIED;
}
/* tokenize expected list of names */
t = require;
while ((w = ap_getword_conf(r->pool, )) && w[0]) {
apr_sockaddr_t *sa;
apr_status_t rv;
char *hash_ptr;
/* stop on apache configuration file comments */
if ((hash_ptr = ap_strchr(w, '#'))) {
if (hash_ptr == w) {
break;
}
*hash_ptr = '\0';
}
/* does the client ip match one of the name? */
rv = apr_sockaddr_info_get(, w, APR_UNSPEC, 0, 0, r->pool);
if (rv == APR_SUCCESS) {
while (sa) {
int match = apr_sockaddr_equal(sa, r->useragent_addr);
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, // APLOGNO(FIXME)
"name_check_authorization: %s for %s: %s",
w, r->useragent_ip, match? "yes": "no");
if (match) {
return AUTHZ_GRANTED;
}
sa = sa->next;
}
}
else {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, // APLOGNO(FIXME)
"name_check_authorization: no sockaddr info for \"%s\"", w);
}
/* stop processing, we are in a comment */
if (hash_ptr) {
break;
}
}
return AUTHZ_DENIED;
}
/* copy of host_parse_config */
static const char *name_parse_config(cmd_parms *cmd, const char *require_line,
const void **parsed_require_line)
{
const char *expr_err = NULL;
ap_expr_info_t *expr;
expr = ap_expr_parse_cmd(cmd, require_line, AP_EXPR_FLAG_STRING_RESULT,
_err, NULL);
if (expr_err)
return apr_pstrcat(cmd->temp_pool,
"Cannot parse expression in require line: ",
expr_err, NULL);
*parsed_require_line = expr;
return NULL;
}
static const authz_prov
access control for dynamic hosts
Hello folks, I have a simple access control use case for which I have not found a clean solution. I want to control access to a service based on the name of the client, however the client is a dynamic host, which implies that: (1) I do not have any control about the reverse DNS => this rules out "Require host" (2) the IP may change arbitrarily => this rules out "Require ip" By browsing around it seems that I'm not alone having this issue, and I have not found any solution for that with apache configuration, nor a matching module in "modules.apache.org" listing. The current workaround is to update the IP manually when it fails. Although I could automate (say query the ip periodically and update & reload the conf if there is a change), ISTM that it really belongs to apache configuration. I would like something like "Require XXX foo.dynamic-dns.somewhere" (where XXX could be "name", "hostname", "dynamic", ...) which would query the NS when the HTTP request is received and check that the corresponding ip is the client IP. I'm planing to develop a small module for that, and as it is somehow quite a basic service it could be a candidate for being added to "modules/aaa/mod_authz_host.c". Another approach could be to extend apache expressions with a function to query the DNS, but that seems a little overkill. Any thoughts? -- Fabien.
Re: mod_macro… backport to 2.4
I've proposed copying/backporting mod_macro to 2.4 ! Fine with me. I would suggest to consider backporting Warning as well, which is used by mod_macro non-regressions tests. -- Fabien.
mod_macro has been added
Hello devs, I've been given the go to add mod_macro to httpd trunk, see r1435811. The module is in modules/core. There are English and French documentations and extensive non regression tests. The module is compiled in with most. It is fully independent, i.e. I have not changed or modified core stuff for the module. I think it is safe and may be considered for backporting to 2.4, as well as the Warning directive added some time ago. I'm not sure about how to advertise the use of the module. Possibly something in the standard default configuration, maybe some carefully designed example macros could be defined and use here and there to show how great that can be? Also, maybe some mention of the module should appear in configuring and sections in the documentation? -- Fabien
Re: mod_macro contributors?
The only unresolved contribution is:
- Paul Mcilwaine paul dot mcilwaine at gmail dot com,
Mike Papper michael at realgirlsmedia dot com
(Mac OS X compiliation issue with boolean/false/true)
Fabien -- can you review/describe it here?
It was a bug report about mod_macro compilation on MacOS X. It defines a
boolean type with true and false constants, which were clashing with
typedef boolean { false, true }; that I was using. I just changed it to
typedef mm_boolean { mm_false, mm_true };, and now I have removed it
anyway in my current dev version because apache does not use a boolean
type and I do not want to add one in order to blend in with the code.
--
Fabien.
Re: mod_macro -- any corporate affiliation?
Can you confirm that a corporate CLA is not required to authorize your contribution of mod_macro to the ASF? In other words, that there is no corporate entity that needs to approve or otherwise has copy rights? Yes, I can confirm that as far as I know there is no corporate contributor license agreement required for mod_macro. -- Fabien.
Re: mod_macro contributors?
Can you respond with a list of mod_macro contributors, minor/bugfix or otherwise, so we can confirm there are no barriers to pulling it in? I'm the author of mod_macro, I did it on my own. Nevertheless, minor fixes, suggestions or help was provided by, as far as I can see from my logs: - Gregg Smith gregg at apachehaus dot com (windows test) - Paul Mcilwaine paul dot mcilwaine at gmail dot com, Mike Papper michael at realgirlsmedia dot com (Mac OS X compiliation issue with boolean/false/true) - Vyacheslav Grebyonki svl at dev4masses dot com (documentation html style, will be turned to xml) - Marc Stern marc dot stern at approach dot be (escape and other issue reports) - Dirk Schreiner Dirk dot Schreiner at tria dot de (issue report with Apache 2.2) - Jorge Schrauwen info at blackdot dot be (64 bits compilation dsp file) - Marc M. Adkins Marc dot M dot Adkins at doorways dot org (Makefile for Windows compilation) - Axel Beckert abe at debian dot org (2 line fix to skip comments) -- Fabien.
Re: mod_macro contributors?
Thanks Fabien. I am striking out on a valid e-mail for Dirk. Do you recall if he even sent in a patch, and if so the size/scope? It was not a patch. It was a bug report about the Warning Error directives which were coredumping on Apache 2.2 because of changes between 2.0 2.2. It triggered version 1.1.9 of mod_macro in November 2007. -- Fabien.
apache style
Hello devs, I'm having a look at : http://httpd.apache.org/dev/styleguide.html which seems to date back 15 years. However when I compile Apache trunk on my laptop, the configuration selects gcc -std=gnu99. Thus I'm wondering whether I could use C99 bold // comments or declarations that can appear where their really needed, or whether I'm implicitely expected to use conservative C89 anyway. If the later is the right option, should not it be enforced explicitly through configure? -- Fabien
Re: 3 questions about inclusion of mod_macro into apache
Dear Stephan, Thank you for your answer. If anyone want to look at the latest source, tell me and I'll make the current dev version available. I've switched to using a hash table instead of an array to store macros, and I have started cleaning up the code to remove traces which dated from apache 1.3 and seem not to be required anymore. If a module, then modules/core, IMHO. Ok. * option util: Move/merge string array processing stuff into server/util.c. This is used when expanding a macro, and could be useful to someone else. I think the -c/-C command line handling does something similar (see arr_elts_getstr() and friends in server/config.c). If these can be merged with mod_macro's functions, then that would be nice. Yes, that is basically what I had in mind, but I have to check the fine details before merging anything. Lazy initialization has the advantage of using less memory if no Macro is used. That's especially true if we put Macro into the core. But I will need to do some source reading before I have any informed opinion on this. Yep. The memory is really a hash table in a temporary pool. We could also start with MU (which looks like less work initially) and then see how things work out. An advantage to a separate module is the separately configurable LogLevel. But as I don't use mod_macro, I don't know if that is important. I do not think that it is important. [...] Warning directive. Yes, seems useful and is small. Put it into core. Sounds reasonnable. *** Question 3: would it make sense to add the ability to remove a macro? I'm not sure that it is useful, as a macro can be overwritten, but it would look more complete that way. That could be UndefMacro xxx or something similar. I don't see any need for that. If there is a use case, then yes. I do not really have a use case, but users have more imagination than me. Without UndefMacro, it can lead to warnings on redefinitions that could be considered noisy and could not be removed. -- Fabien.
3 questions about inclusion of mod_macro into apache
Dear httpd devs, Mod_macro has been accepted for inclusion into Apache HTTP Server, and my commit access has been extended to httpd. I should do it when I have time and I'm given the go ahead, hopefully within the month. Some preliminary questions before doing anything. The current module directives are: - Macro + Use directives to define use a macro - Error directive, now redundant as one has been added since 2.3.9 - Warning directive, similar to error but which does not stop Macros are kept in a temporary memory pool and can only be used at configuration time. They cannot be defined and/or used within a .htaccess file for instance. This is a feature. *** Question 1: there are several possible strategies to include the module * option module vs core module - add the module more or less as is after some cleanup, for instance under modules/core, or under a new modules/macro directory. core - incorporate the module in core (mostly server/core.c). I'm not sure how Apache core is used, and whether such features should or should not be included. From a language perspective, it makes sense to have macros there, together with preprocessor-like configuration stuff such as *Define If* Else* Error Include*. * option util: Move/merge string array processing stuff into server/util.c. This is used when expanding a macro, and could be useful to someone else. * option config: ideally, macros would require pre/post read config hooks which do not exist. The existing pre/post config are executed after the file has been read, and this is too late. Adding such a hook would avoid a lazy initialization, but maybe adding a hook just for such a limited benefit is not really worth it. Directive Define handling also uses a lazy initialization to deal with the very same issue. It seems to me that the possible choices are: - M module - MU module+util - MUC module+util+config - C core - CU core+util - CUC core+util+config I am in favor of choosing CU, or at default MU. If this is kept outside core (choices M*), I think that it should nevertheless be included in the default compilation and installation. *** Question 2: obviously, I'll remove the Error directive which is now provided in core. However, should I keep the Warning directive, possibly added to core independently of what is done with the macro stuff? *** Question 3: would it make sense to add the ability to remove a macro? I'm not sure that it is useful, as a macro can be overwritten, but it would look more complete that way. That could be UndefMacro xxx or something similar. -- Fabien
Re: mod_macro into apache ?
On Sun, 11 Nov 2012, Jim Jagielski wrote: I've been a fan of mod_macro since day 1... in fact, my 1st ApacheCon preso in 2000 mentions it. I still use it. I still recommend it. - Rainer Jung+1 - Stefan Fritsch +1 - Nick Gearls+1 - Igor Galić +1 - Nick Kew +1 - MATSUMOTO Ryosue +1 - Günter Knauf +1 - Rich Bowen +1 Hopefull, someone will tell me if I have to do something. -- Fabien.
Re: mod_macro into apache ?
On Sun, 11 Nov 2012, Jim Jagielski wrote: I've been a fan of mod_macro since day 1... in fact, my 1st ApacheCon preso in 2000 mentions it. I still use it. I still recommend it. - Rainer Jung+1 - Stefan Fritsch +1 - Nick Gearls+1 - Igor Galić +1 - Nick Kew +1 - MATSUMOTO Ryosue +1 Good. I'm not sure when a conclusion is reached to whether the module is accepted in core. Someone will tell me, I guess... On the practical side, I do not think that my commit authorization on apache svn server includes httpd. Maybe a committer can get the latest version and commit the c and html documentation where it should belong. Or I could do it, which would make it clearer if need be that I do donate the code as I'm the author, if I'm given the authorization. Also I'm not sure about whether it should be included or not in the default build. -- Fabien.
mod_macro into apache ?
Hello devs, I have developed and maintained a small module called mod_macro since 1998. It is currently available at: http://people.apache.org/~fabien/mod_macro/ I started it one day as was fed up with copy-pasting configuration directives from one virtual host to the next and one directory to the next. It includes Define/Use of configuration macro, as well as Error/Warning macros. The code is fairly stable (14 years:-). I would like to donate the code so that it could be integrated with apache as a standard module. The main reason for that is that what is done is some preprocessing that do not really belong to an external module, as the right configuration time hooks do not exist, so I have to guess. If the module was integrated in the configuration handling of apache, there would be no need for guessing, thus it could be cleaner. Moreover, I think that such features should have been included with apache from the start. -- Fabien
RE: help with apache configuration logic...
Take a look at the worker.c file, worker_pre_config function for an example of how to modify the configuration tree. Ok. I'm going to investigate that. It seems that I'll need to restructure the whole stuff for apache 2 instead of the minimum time port I hopped for initially. Fabien.
help with apache configuration logic...
Hello Apache-people, I'm in the process of porting to apache 2 a module I developped for apache 1.3. The 'mod_macro' module add macro definition capabilities to apache configuration files. Macros are expanded on the fly and parsed. With apache 1.3, I needed an initialization phase each time a new configuration cycle is started, as there are two analyses of the configuration file each time apache is launched. The hack I found was to notice that the temporary pool has changed to re-initialized my internal data structures which holds the description of macros... quite poor. Now with apache 2, I digged out in the source code a 'pre_config' and 'post_config' hook that look just fine, so I was planing to use that instead of the previous hack. However : 1/ the apache configuration is still read twice. well, why not if it pleases you. 2/ the pre_config hook is run *AFTER* the configuration file is read. Indeed, you can see that in main.c where ap_run_pre_config() is called after ap_read_config() Thus here are my questions: 1/ as 'PRE' is a latin prefix which means before, would it be possible for the sanity of the developpers to either: a/ call it *before* the configuration is read. b/ or rename it 'post_config';-) then the 'post_config' can be renamed 'post_post_config';-) 2/ if the pre_config is to be run anyway after the configuration file is read, could you suggest another hook I could use ? I can't see any... and the developper documentation is rather scarse and not up to date. 3/ or explain what I missed in the source code to understand the logic behind all that. Thanks in advance for your help! -- Fabien.
