Change to Module DB
User ID : 186 Title: mod_authnz_ibmdb2 Details : https://modules.apache.org/search.php?id=956
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 05:07 AM, Yehuda Katz wrote: On Tue, Jan 22, 2013 at 7:10 PM, Daniel Gruno rum...@cord.dk mailto:rum...@cord.dk wrote: I implore you to try out the new site, both as a regular visitor and as a (fake) module author, and see if this isn't a vast improvement of what we have. To whom or where to we post bugs? - Y If you find a bug, post it to me or on the list, whichever you think is appropriate. Obviously, a huge gaping security hole should be posted more private ;) Since it's an infrastructure operated site, I suppose you can also post a JIRA ticket. If/once the site goes live, I suspect modules-...@httpd.apache.org would be the right place to post such bugs. For those interested in the source code, it's available at sourceforge at the moment (I did not want to trouble infrastructure or httpd by spamming svn updates on a site that's not an asf site yet) at https://sourceforge.net/p/modulesao/code/ - anyone interested is, as said earlier, most welcome to join in and make contributions. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On Jan 22, 2013, at 5:29 PM, Daniel Gruno rum...@cord.dk wrote: This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. -1 Veto. +1 for updating the site and all your comments and suggestions. -1 for lazy consensus. Have you contacted Infra about supporting the newly designed site?
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
Suggestion: http://modules.humbedooh.com/search.lua Can you make a blank search entry default to wildcard glob? How else to search for all 'logging' modules, for example, without having to enter in something stupid like 'm' for a search term...
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 04:42 PM, Jim Jagielski wrote: On Jan 22, 2013, at 5:29 PM, Daniel Gruno rum...@cord.dk wrote: This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. -1 Veto. +1 for updating the site and all your comments and suggestions. -1 for lazy consensus. Have you contacted Infra about supporting the newly designed site? Lazy consensus was retracted in my previous email, so no need for a veto :). As to infra, yes, I am a part of the infrastructure team myself, and am in dialogue with gavin who currently operates the site. Switching to a new httpd with the works should not be a big issue - it's our software after all ;). As for the search stuff, yes I'll take a look at making globs work, though you could just click on 'Browse' and then select the 'logging' tag. With regards, Daniel. PS: DOAP file support and email notifications to authors have also been added since the time of my last email.
mod_remoteip does NOT change access-log IP
hi LoadModuleremoteip_module modules/mod_remoteip.so RemoteIPHeaderX-Forwarded-For RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 PHP - fine, exactly how it should do: _SERVER[SERVER_ADDR] 10.0.0.99 _SERVER[SERVER_PORT] 8080 _SERVER[REMOTE_ADDR] 10.0.0.99 BUT access-log contains the ip of the apache trafficserver this is a major problem for replace mod_rafp with mod_remoteip because webalizer-usages are more or less useless 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) signature.asc Description: OpenPGP digital signature
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On Wed, Jan 23, 2013 at 4:04 AM, Daniel Gruno rum...@cord.dk wrote: If you find a bug, post it to me or on the list, whichever you think is appropriate. OK. Bug I found seems to be fixed (since about 2300 EST). When I clicked on the link to modules.lua on projects.lua, there was some error. Now it appears to be working. (and I just noticed that you sent me a message indicating that.) Several comments: - Clicking remove project should probably prompt Are you sure?. - It would be nice if the title would change based on the page you are on so that it is easier to use the browser's back/forward and history. - Y
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 06:04 PM, Yehuda Katz wrote: On Wed, Jan 23, 2013 at 4:04 AM, Daniel Gruno rum...@cord.dk mailto:rum...@cord.dk wrote: If you find a bug, post it to me or on the list, whichever you think is appropriate. OK. Bug I found seems to be fixed (since about 2300 EST). When I clicked on the link to modules.lua on projects.lua, there was some error. Now it appears to be working. (and I just noticed that you sent me a message indicating that.) Several comments: - Clicking remove project should probably prompt Are you sure?. - It would be nice if the title would change based on the page you are on so that it is easier to use the browser's back/forward and history. - Y Yeah, I saw the bug and got it fixed - it appears to be a standard lua error that usually requires a small workaround. Yes, clicking remove should prompt - I'll add that, thanks for the tip :) And as for the title, I'll get around to that as well :) With regards, Daniel.
Re: mod_remoteip does NOT change access-log IP
however: http://vova-zms.blogspot.co.at/2012/07/install-modrpaf-with-apache-24.html patched mod_rpaf works with 2.4 but it would be really nice to have EXACTLY it's behavior in mod_remoteip because i see no way how i sell my customers chaning usages nor can i change the configuration of logging because a very mixed environement of vurtual hosts with or without trafficserver Am 23.01.2013 17:06, schrieb Reindl Harald: hi LoadModuleremoteip_module modules/mod_remoteip.so RemoteIPHeaderX-Forwarded-For RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 PHP - fine, exactly how it should do: _SERVER[SERVER_ADDR]10.0.0.99 _SERVER[SERVER_PORT]8080 _SERVER[REMOTE_ADDR]10.0.0.99 BUT access-log contains the ip of the apache trafficserver this is a major problem for replace mod_rafp with mod_remoteip because webalizer-usages are more or less useless 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) signature.asc Description: OpenPGP digital signature
Re: mod_remoteip does NOT change access-log IP
hmpf - with mod_rpaf on httpd 2.4 the access-log-ip is correct but the REMOTE_ADDR variable in PHP-scripts has the proxy-IP means i can not upgrade production to 2.4 because mod_remoteip will destory usages and mod_rpaf security because you have inside php-scripts a LAN address from the proxy mod_rpaf on httpd 2.2 replaces for sure ANY place like access-log, error-log and REMOTE_ADDR in scripts with the X-Forwarded-For from the trusted apache trafficserver SERVER_ADDR 10.0.0.99 SERVER_PORT 8080 REMOTE_ADDR 10.0.0.103 Am 23.01.2013 18:08, schrieb Reindl Harald: however: http://vova-zms.blogspot.co.at/2012/07/install-modrpaf-with-apache-24.html patched mod_rpaf works with 2.4 but it would be really nice to have EXACTLY it's behavior in mod_remoteip because i see no way how i sell my customers chaning usages nor can i change the configuration of logging because a very mixed environement of vurtual hosts with or without trafficserver Am 23.01.2013 17:06, schrieb Reindl Harald: hi LoadModuleremoteip_module modules/mod_remoteip.so RemoteIPHeaderX-Forwarded-For RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 PHP - fine, exactly how it should do: _SERVER[SERVER_ADDR] 10.0.0.99 _SERVER[SERVER_PORT] 8080 _SERVER[REMOTE_ADDR] 10.0.0.99 BUT access-log contains the ip of the apache trafficserver this is a major problem for replace mod_rafp with mod_remoteip because webalizer-usages are more or less useless 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) signature.asc Description: OpenPGP digital signature
Re: Plea for eyes (and votes) on STATUS proposals
On Jan 22, 2013, at 8:49 PM, Daniel Ruggeri drugg...@primary.net wrote: As usual, mileage varies. I didn't test the case of a proxypass at server level with a balancer there as well... here is my config: BalancerInherit Off Proxy balancer://mycluster BalancerMember https://127.0.0.1:4433 route=1 /Proxy ProxyPass /proxy/ balancer://mycluster/ Listen 192.168.0.103:80 VirtualHost 192.168.0.103:80 ... ProxyPass /proxy2/ balancer://mycluster/ /VirtualHost Attempts to hit /proxy/ on that vhost work every time (with BalancerInherit Off). Attempts to hit /proxy2/ return a 503 and AH01171: balancer://mycluster: No workers in balancer. I'd say that the former is definitely unexpected but the latter is fairly reasonable. There was a ProxyPassInherit as part of the original patch... maybe that needs to be revisited? iirc, there were people who did not like that :) Do you mean PPI in *addition to* BI?
Re: Plea for eyes (and votes) on STATUS proposals
On 1/23/2013 11:30 AM, Jim Jagielski wrote: iirc, there were people who did not like that :) Do you mean PPI in *addition to* BI? Yes - I always believe in giving the admin the control to decide the what's and how... The case of ProxyPass at server level (regardless of a balancer in play or not) is enough to have ProxyPassInherit as a companion to BalancerInherit. Regarding the first statement, (maybe I read the conversation wrong) I don't think Graham's concerns were an outright objection to the idea. I think he asked for the same stuff I mentioned in the STATUS file - just better documentation to understand what does/does not get changed as a result of disabling these directives and the inconsistencies that could occur when enabled. I'm sure it goes without saying, but I will anyway. To avoid very confused server admins, it's important that these default to On and preserve the way things have always been (this is what has been proposed, after all). -- Daniel Ruggeri
HTTPd hackathon at ACNA 2013
Hi folks, For those of you going to ACNA (And I hope it's a lot of you..!), we have a petition for a hackathon set up at http://wiki.apache.org/apachecon/HackathonNA13 - if you're interested, please bump the number a bit, so the producer etc can see that we need a spot if so. With regards, Daniel.
