Re: [vote] mod_ldap
On 07.07.2011 18:55, William A. Rowe Jr. wrote: > Only presently available options are available as choices to end this > now unproductive discussion [any heretofore unseen complete abstration > of ldap cannot be considered with no patches offered]. This vote is > limited to the scope of the httpd project and expresses a preference, > there is no technical basis demonstrated to carry a veto. > > [X] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk > (binding mod_ldap to ldap libs) +1
Re: [vote] mod_ldap
> [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk > (binding mod_ldap to ldap libs) +1 (-0 at best on any of the others)
HTTPD 2.2.17 issue on Fedora 15 with listening on IPv4
If this is the wrong list to ask for help on this please redirect me. We are porting our application to Fedora 15 and to systemd from SysV init. The httpd configuraturation we are using work without problem on earlier Fedora 13 systems. We are hitting an odd problem with httpd handling requests on localhost:80 over IPv4. The configuration allows access without authenication but we get a 401 error. However repeat the request using IPv6 and it it works. If we restart httpd (systemctl restart httpd.service) the problem goes away. We have a set of identical hardware running identical software with identical config and not all systems show this problem. Leading me to expect its a race condition during startup. Here is a fragment of the httpd.conf file: ... rewrite rules ... #+ localhost auth file Order allow,deny Allow from 127.0.0.1 Allow from ::1 Satisfy Any #- localhost auth file ... I test this with: curl -4 http://localhost:80/XML/ curl -6 http://localhost:80/XML/ I'm willing to debug and patch the code to get to the bottom of the problem but would like to know if this is a known problem. Any pointers on where to start looking in the code would be welcome as well. Barry
Re: Remaining LDAP issues?
On Jul 8, 2011, at 1:15 AM, William A. Rowe Jr. wrote: > Starting a fresh thread to identify the actual issues that are blocking > the 2.3.13-beta, along with fresh checkouts and build trees... > > I immediately noticed that it's confusing that --enable-authnz-ldap etc > don't work without --with-ldap. What configuration logic could make this > all easier for users who want ldap auth? > Well, we kind of have the same situation with SSL, don't we. We use --with-ssl to point to the location of the SSL libs and use --enable-ssl to enable mod_ssl.
Re: HTTPD 2.2.17 issue on Fedora 15 with listening on IPv4
On 07/08/2011 02:30 PM, Barry Scott wrote: If this is the wrong list to ask for help on this please redirect me. We are porting our application to Fedora 15 and to systemd from SysV init. The httpd configuraturation we are using work without problem on earlier Fedora 13 systems. We are hitting an odd problem with httpd handling requests on localhost:80 over IPv4. The configuration allows access without authenication but we get a 401 error. However repeat the request using IPv6 and it it works. If we restart httpd (systemctl restart httpd.service) the problem goes away. We have a set of identical hardware running identical software with identical config and not all systems show this problem. Leading me to expect its a race condition during startup. Here is a fragment of the httpd.conf file: ... rewrite rules ... #+ localhost auth file Order allow,deny Allow from 127.0.0.1 Allow from ::1 Satisfy Any #- localhost auth file ... I test this with: curl -4 http://localhost:80/XML/ curl -6 http://localhost:80/XML/ I'm willing to debug and patch the code to get to the bottom of the problem but would like to know if this is a known problem. Any pointers on where to start looking in the code would be welcome as well. Does this still happen if you force NetworkManager to wait for the network to actually come up? systemctl enable NetworkManager-wait-online.service Paul.
Re: Question about publishing module
can you saw when this will be done? On Fri, Jul 1, 2011 at 7:41 AM, Nick Kew wrote: > > On 1 Jul 2011, at 12:25, Joshua ## wrote: > > > Hey everyone, i know this might not be the right place to ask this. But > for my final year project, an Apache module was developed that helps to > mitigate session hijacking attacks. I was wondering how do i publish this > module on apache.org? > > The usual way would be to enter it at modules.apache.org. > > That's currently migrating to different hardware and getting updated, > so you might want to wait until that's done. > > -- > Nick Kew > > Available for work, contract or permanent > http://www.webthing.com/~nick/cv.html > >
Re: HTTPD 2.2.17 issue on Fedora 15 with listening on IPv4
On Fri, Jul 8, 2011 at 9:30 AM, Barry Scott wrote: > If this is the wrong list to ask for help on this please redirect me. user support mailing list http://httpd.apache.org/lists.html#http-users
Re: Question about publishing module
a week or so. I at least didn't have any cycles this week. i Joshua ## wrote: >can you saw when this will be done? > >On Fri, Jul 1, 2011 at 7:41 AM, Nick Kew wrote: > >> >> On 1 Jul 2011, at 12:25, Joshua ## wrote: >> >> > Hey everyone, i know this might not be the right place to ask this. But >> for my final year project, an Apache module was developed that helps to >> mitigate session hijacking attacks. I was wondering how do i publish this >> module on apache.org? >> >> The usual way would be to enter it at modules.apache.org. >> >> That's currently migrating to different hardware and getting updated, >> so you might want to wait until that's done. >> >> -- >> Nick Kew >> >> Available for work, contract or permanent >> http://www.webthing.com/~nick/cv.html >> >>
Re: load order dependency between mod_ldap and mod_authnz_ldap
[answering this backwards] On 08 Jul 2011, at 4:10 AM, Nick Kew wrote: I am therefore vetoing this move of apr_ldap from APR to httpd. Hang on! How long ago did this move happen, and when did you first raise concerns? The move happened on the 31st of May, and my concerns were first raised that same day: http://mail-archives.apache.org/mod_mbox/httpd-cvs/201105.mbox/%3c20110531171012.dfc812388...@eris.apache.org%3E The announcement that the move was to take place was declared on the dev@apr mailing list: http://www.mail-archive.com/dev%40apr.apache.org/msg24081.html In reply I asked "Can you point out for me the thread on the dev@httpd list when this was decided? Why are we discussing changes to httpd on the dev@apr list?". This particular question was ignored. Further on in the thread I made the following statement: http://www.mail-archive.com/dev%40apr.apache.org/msg24086.html "Leaving end users to discover that whole APIs have mysteriously disappeared without warning or explanation, without those APIs having been marked as deprecated, is grounds for a veto. So is the idea that another project will tolerate a code dump from one project to another, with the corresponding disruption to vendors that will result. In addition, APR has been a standalone library, depended on by many projects external to the ASF for many years, APR is not part of httpd, and code isn't interchangeable between them." This statement was not challenged. I eventually formally vetoed the move on 26 June as I warned I would do after the disastrous attempt to release v2.3.13 of httpd: http://www.mail-archive.com/dev%40httpd.apache.org/msg51301.html This veto has to date been ignored, and the grounds for the veto as stated remain unchallenged by wrowe. Regards, Graham --
Re: load order dependency between mod_ldap and mod_authnz_ldap
On Thu, Jul 07, 2011 at 11:59:20PM +0200, Graham Leggett wrote: > On 04 Jul 2011, at 6:48 PM, Joe Orton wrote: > > >It's incumbent on you to provide specific technical objections if > >vetoing code, not this hand-waving "objections must exist because > >of X". > > I have already done so. If you disagree with the objection, or do > not understand the objection, engage the objection directly so it > can be resolved. I've done exactly that twice in this thread. I have not seen any attempt to concisely express a specific technical objection, rather than this hand-waving stuff about "inappropriateness", and how the API is "wrong", how we must necessarily reject code because of the APR vote, and how it does not solve a problem which you say will be solved better by reimplementing the code in APR. If you don't have specific technical objections (and hence, any reason for veto) then you should just offer up an alternative solution and we can have a consensus vote to pick one, and move on. > We are not discussing the removal of apr_ldap from APR, we are > discussing the addition of ap_ldap to httpd. I only engaged in the discussion about the removal of the code from APR because you explicitly called that out as motivation for your veto: http://www.mail-archive.com/dev@httpd.apache.org/msg51396.html "I have already stated the basis for the veto: every single apparent flaw in the apr_ldap code that caused wrowe to remove it from APR is still present in the code that wrowe dumped into httpd." So if that is not the basis of your veto after all, let's drop it. But I am no closer to understanding the basis for veto. > In the case of MacOSX, it breaks for me as follows: > > checking whether to enable mod_authnz_ldap... checking dependencies > checking whether to enable mod_authnz_ldap... configure: error: > mod_authnz_ldap has been requested but can not be built due to > prerequisite failures Did you build with --with-ldap as well? If so, can you post the complete config.log? Regards, Joe
[PATCH 51489] ProxyPassReverse issue + patch
Hi Apache developers,
I'm using Apache as a reverse proxy in a simple load balancer setup.
I use ProxyPassReverse in order to re-write the backend server name in
HTTP redirections (ie. in the Location header of the HTTP response).
My configuration for the virtual host essentially looks like this:
BalancerMember http://server-1.local status=-SE
BalancerMember http://server-2.local status=-SE
ServerName frontend.local
ProxyPass balancer://196f045aca6adc82a0b6eea93ed286a1/
ProxyPassReverse balancer://196f045aca6adc82a0b6eea93ed286a1/
Now, I was wondering why redirects get an additional slash between the
server name and the path. Example:
1. The backend server redirects the URL http://server-1.local/foo to
the URL http://server-1.local/foo/ because this is actually a
directory (so far no issue)
2. With the configuration above the reverse proxy redirects the URL
http://frontend.local/foo to http://frontend.local//foo/
What I bother about is the additional slash before '/foo/', so I digged
into the source code and found the following lines in
modules/proxy/proxy_util.c:
PROXY_DECLARE(const char *) ap_proxy_location_reverse_map(request_rec *r,
proxy_dir_conf *conf, const char *url)
{
[...]
l1 = strlen(url);
[...]
for (i = 0; i < conf->raliases->nelts; i++) {
if (ap_proxy_valid_balancer_name((char *)real, 0) &&
(balancer = ap_proxy_get_balancer(r->pool, sconf, real))) {
int n, l3 = 0;
proxy_worker **worker = (proxy_worker
**)balancer->workers->elts;
const char *urlpart = ap_strchr_c(real, '/');
if (urlpart) {
if (!urlpart[1])
urlpart = NULL;
else
l3 = strlen(urlpart);
}
for (n = 0; n < balancer->workers->nelts; n++) {
l2 = strlen((*worker)->s->name);
if (urlpart) {
/* urlpart (l3) assuredly starts with its own '/' */
if ((*worker)->s->name[l2 - 1] == '/')
--l2;
if (l1 >= l2 + l3
&& strncasecmp((*worker)->s->name, url, l2)
== 0
&& strncmp(urlpart, url + l2, l3) == 0) {
u = apr_pstrcat(r->pool, ent[i].fake, &url[l2 +
l3],
NULL);
return ap_construct_url(r->pool, u, r);
}
}
else if (l1 >= l2 && strncasecmp((*worker)->s->name,
url, l2) == 0) {
u = apr_pstrcat(r->pool, ent[i].fake, &url[l2], NULL);
return ap_construct_url(r->pool, u, r);
}
worker++;
}
[...]
Right now I don't really understand the reason for the special casing of
urlpart == "/" in modules/proxy/proxy_util.c, lines 1126 to 1129 (SVN
rev. 1144374). If urlpart == "/", then the code in lines 1151 and 1152
gets executed, which seems to add the slash.
I tried to remove the special casing (see submitted patch), and
apparently the removal fixes the issue.
Does anybody know the reason for the special casing mentioned above?
If not I want to suggest to commit my patch.
Regards,
Micha
Re: [PATCH 51489] ProxyPassReverse issue + patch
This seems more like a job for mod_rewrite to me.
On Jul 8, 2011 12:32 PM, "Micha Lenk" wrote:
> Hi Apache developers,
>
> I'm using Apache as a reverse proxy in a simple load balancer setup.
> I use ProxyPassReverse in order to re-write the backend server name in
> HTTP redirections (ie. in the Location header of the HTTP response).
> My configuration for the virtual host essentially looks like this:
>
>
> BalancerMember http://server-1.local status=-SE
> BalancerMember http://server-2.local status=-SE
>
>
> ServerName frontend.local
>
>
> ProxyPass balancer://196f045aca6adc82a0b6eea93ed286a1/
> ProxyPassReverse balancer://196f045aca6adc82a0b6eea93ed286a1/
>
>
>
> Now, I was wondering why redirects get an additional slash between the
> server name and the path. Example:
>
> 1. The backend server redirects the URL http://server-1.local/foo to
> the URL http://server-1.local/foo/ because this is actually a
> directory (so far no issue)
>
> 2. With the configuration above the reverse proxy redirects the URL
> http://frontend.local/foo to http://frontend.local//foo/
>
> What I bother about is the additional slash before '/foo/', so I digged
> into the source code and found the following lines in
> modules/proxy/proxy_util.c:
>
> PROXY_DECLARE(const char *) ap_proxy_location_reverse_map(request_rec *r,
> proxy_dir_conf *conf, const char *url)
> {
> [...]
> l1 = strlen(url);
> [...]
> for (i = 0; i < conf->raliases->nelts; i++) {
> if (ap_proxy_valid_balancer_name((char *)real, 0) &&
> (balancer = ap_proxy_get_balancer(r->pool, sconf, real))) {
> int n, l3 = 0;
> proxy_worker **worker = (proxy_worker
> **)balancer->workers->elts;
> const char *urlpart = ap_strchr_c(real, '/');
> if (urlpart) {
> if (!urlpart[1])
> urlpart = NULL;
> else
> l3 = strlen(urlpart);
> }
> for (n = 0; n < balancer->workers->nelts; n++) {
> l2 = strlen((*worker)->s->name);
> if (urlpart) {
> /* urlpart (l3) assuredly starts with its own '/' */
> if ((*worker)->s->name[l2 - 1] == '/')
> --l2;
> if (l1 >= l2 + l3
> && strncasecmp((*worker)->s->name, url, l2)
> == 0
> && strncmp(urlpart, url + l2, l3) == 0) {
> u = apr_pstrcat(r->pool, ent[i].fake, &url[l2 +
> l3],
> NULL);
> return ap_construct_url(r->pool, u, r);
> }
> }
> else if (l1 >= l2 && strncasecmp((*worker)->s->name,
> url, l2) == 0) {
> u = apr_pstrcat(r->pool, ent[i].fake, &url[l2], NULL);
> return ap_construct_url(r->pool, u, r);
> }
> worker++;
> }
> [...]
>
> Right now I don't really understand the reason for the special casing of
> urlpart == "/" in modules/proxy/proxy_util.c, lines 1126 to 1129 (SVN
> rev. 1144374). If urlpart == "/", then the code in lines 1151 and 1152
> gets executed, which seems to add the slash.
>
> I tried to remove the special casing (see submitted patch), and
> apparently the removal fixes the issue.
>
> Does anybody know the reason for the special casing mentioned above?
> If not I want to suggest to commit my patch.
>
> Regards,
> Micha
Re: load order dependency between mod_ldap and mod_authnz_ldap
On 08 Jul 2011, at 6:01 PM, Joe Orton wrote: I have already done so. If you disagree with the objection, or do not understand the objection, engage the objection directly so it can be resolved. I've done exactly that twice in this thread. I have not seen any attempt to concisely express a specific technical objection, rather than this hand-waving stuff about "inappropriateness", and how the API is "wrong", how we must necessarily reject code because of the APR vote, and how it does not solve a problem which you say will be solved better by reimplementing the code in APR. If you don't have specific technical objections (and hence, any reason for veto) then you should just offer up an alternative solution and we can have a consensus vote to pick one, and move on. We have already put the solution to a vote, and this is the outcome: http://www.mail-archive.com/dev@apr.apache.org/msg22061.html I completely do not understand one bit why we are wasting yet more time voting yet again on a solution. Just pick up a keyboard, a copy of the draft LDAP RFC, and finish the work we agreed to do. If you believe someone else should do the work and not you, ask, and as a courtesy, explain why you believe it shouldn't be you. If you believe this work should be prioritised for inclusion in httpd v2.4 and apr-util v1.4, say so. In the case of MacOSX, it breaks for me as follows: checking whether to enable mod_authnz_ldap... checking dependencies checking whether to enable mod_authnz_ldap... configure: error: mod_authnz_ldap has been requested but can not be built due to prerequisite failures Did you build with --with-ldap as well? If so, can you post the complete config.log? It builds with --with-ldap, but this should not be necessary - it's only if your library is in a non standard location that --with-ldap should be necessary. Regards, Graham --
lua-apr and mod_lua
I have not yet had a chance to look into lua-apr ( http://peterodding.com/code/lua/apr/ ) but it might be darned handy re: mod_lua.
Re: Remaining LDAP issues?
On 7/8/2011 8:48 AM, Jim Jagielski wrote: > > On Jul 8, 2011, at 1:15 AM, William A. Rowe Jr. wrote: > >> Starting a fresh thread to identify the actual issues that are blocking >> the 2.3.13-beta, along with fresh checkouts and build trees... >> >> I immediately noticed that it's confusing that --enable-authnz-ldap etc >> don't work without --with-ldap. What configuration logic could make this >> all easier for users who want ldap auth? > > Well, we kind of have the same situation with SSL, don't > we. We use --with-ssl to point to the location of the SSL > libs and use --enable-ssl to enable mod_ssl. True. I'm thinking of the generalized case where openldap (and, as you point out, openssl) live in their usual system paths. It seems like --enable-ssl could imply --with-ssl[noarg] and --enable-authnz-ldap could imply --enable-ldap which could imply --with-ldap[noarg]. It only tripped me because my old ./config never set apr flags, I had built apr[-util] in that test framework out-of-tree. So perhaps my surprise would be unusual for most users.
Re: [vote] mod_ldap
On 07 Jul 2011, at 6:55 PM, William A. Rowe Jr. wrote: Only presently available options are available as choices to end this now unproductive discussion [any heretofore unseen complete abstration of ldap cannot be considered with no patches offered]. This vote is limited to the scope of the httpd project and expresses a preference, there is no technical basis demonstrated to carry a veto. Five weeks ago you unilaterally chose the following option despite being warned at the time on dev@apr that it would be vetoed: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) Calling for a vote 5 weeks later in an attempt to legitimise your action does not get around the rules of veto, which are "No veto can be overruled"[1]. This vote is void. [1] http://httpd.apache.org/dev/guidelines.html [2] vote thread removing ldap from apr-2.x; http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3c4bd46614.6010...@rowe-clan.net%3E This statement is misleading, I ask that people follow this link to see for themselves. This vote thread called for "Abandon apr_ldap_* API's to httpd 2.3 ldap, including required autoconf", not the removal of ldap from apr- v2.x. This issue was not brought to the attention of the dev@httpd list, nor was dev@httpd invited to vote on it, and therefore this vote too is void. Regards, Graham --
Re: Question about publishing module
On 8 Jul 2011, at 15:53, Joshua ## wrote: > can you saw when this will be done? Waiting was only a suggestion. If you don't want to wait, there's no harm entering it in the current module index. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: lua-apr and mod_lua
On 7/8/11 1:23 PM, "Brian McCallister" wrote: > I have not yet had a chance to look into lua-apr ( > http://peterodding.com/code/lua/apr/ ) but it might be darned handy > re: mod_lua. I looked at it and it seems to not be that great of a fit. It uses global pools all over the place, so it may be hard to integrate with existing httpd-like stuff. -- Brian Akins
