Re: Apache server-status Monitoring / why is it only available through http?
might this be something - where mod_systemd can be extended? I have never used it but it already seems to provide some stats. Am 26.03.2018 um 12:17 schrieb Stefan Priebe - Profihost AG: > > Am 24.03.2018 um 15:28 schrieb Eric Covener: >> On Sat, Mar 24, 2018 at 10:18 AM, Stefan Priebe - Profihost AG >> wrote: >>> Hello, >>> >>> is there any reason why the srever-status output isn't: >>> - available through a local unix socket - so you can grab it even all >>> workers are busy >> >> There are some slightly weird third-party and partial solutions for this >> >> - mod_backdoor (additional listener w/ dedicated thread for >> emergencies, not AF_UNIX though) >> - scripts that separately parse an on-disk "ScoreBoardFile" > > Both sounds like really ugly hacks. ScoreBoardFile isn't recommanded for > performance reasons (see httpd docs). > > mod_backdoor does not even survive a restart (i didn't test but there is > a note in the README). > > So both ways do not seem to be really usable. > >> Maybe mod_backdoor with a new name + limitations addressed + more >> eyeballs would be worth looking at for adding to the distribution. >> http://people.apache.org/~trawick/mod_backdoor.txt >> >>> - available in a machine readable format even it might be csv... >> >> There is a machine-readable option in the query string, append ?auto >> to the URL. >> >> -/- >> >> Also worth mentioning but I don't really know anything about it is >> mod_bmx: https://github.com/hyperic/mod_bmx >>
Re: Apache server-status Monitoring / why is it only available through http?
Am 24.03.2018 um 15:28 schrieb Eric Covener: > On Sat, Mar 24, 2018 at 10:18 AM, Stefan Priebe - Profihost AG > wrote: >> Hello, >> >> is there any reason why the srever-status output isn't: >> - available through a local unix socket - so you can grab it even all >> workers are busy > > There are some slightly weird third-party and partial solutions for this > > - mod_backdoor (additional listener w/ dedicated thread for > emergencies, not AF_UNIX though) > - scripts that separately parse an on-disk "ScoreBoardFile" Both sounds like really ugly hacks. ScoreBoardFile isn't recommanded for performance reasons (see httpd docs). mod_backdoor does not even survive a restart (i didn't test but there is a note in the README). So both ways do not seem to be really usable. > Maybe mod_backdoor with a new name + limitations addressed + more > eyeballs would be worth looking at for adding to the distribution. > http://people.apache.org/~trawick/mod_backdoor.txt > >> - available in a machine readable format even it might be csv... > > There is a machine-readable option in the query string, append ?auto > to the URL. > > -/- > > Also worth mentioning but I don't really know anything about it is > mod_bmx: https://github.com/hyperic/mod_bmx >
Re: Apache server-status Monitoring / why is it only available through http?
On Sat, Mar 24, 2018 at 10:18 AM, Stefan Priebe - Profihost AG wrote: > Hello, > > is there any reason why the srever-status output isn't: > - available through a local unix socket - so you can grab it even all > workers are busy There are some slightly weird third-party and partial solutions for this - mod_backdoor (additional listener w/ dedicated thread for emergencies, not AF_UNIX though) - scripts that separately parse an on-disk "ScoreBoardFile" Maybe mod_backdoor with a new name + limitations addressed + more eyeballs would be worth looking at for adding to the distribution. http://people.apache.org/~trawick/mod_backdoor.txt > - available in a machine readable format even it might be csv... There is a machine-readable option in the query string, append ?auto to the URL. -/- Also worth mentioning but I don't really know anything about it is mod_bmx: https://github.com/hyperic/mod_bmx
Apache server-status Monitoring / why is it only available through http?
Hello, is there any reason why the srever-status output isn't: - available through a local unix socket - so you can grab it even all workers are busy - available in a machine readable format even it might be csv... Thanks! Greets, Stefan
Re: server-status script donated to ASF
On Sat, Mar 25, 2017 at 8:07 PM, Tom Browder wrote: > On Sat, Mar 25, 2017 at 18:12 Eric Covener wrote: >> On Sat, Mar 25, 2017 at 6:18 PM, Tom Browder >> wrote: >> > LuaMapHandler ^/server-status$ /server-status.lua >> >> I think the second parm here is a filesystem path and not a URL-path. Success! Thanks so much, Eric. Best regards, -Tom
Re: server-status script donated to ASF
On Sat, Mar 25, 2017 at 18:12 Eric Covener wrote: > On Sat, Mar 25, 2017 at 6:18 PM, Tom Browder > wrote: > > LuaMapHandler ^/server-status$ /server-status.lua > > I think the second parm here is a filesystem path and not a URL-path. Okay, I'll try that. Thanks. -Tom
Re: server-status script donated to ASF
On Sat, Mar 25, 2017 at 6:18 PM, Tom Browder wrote: > LuaMapHandler ^/server-status$ /server-status.lua I think the second parm here is a filesystem path and not a URL-path.
Re: server-status script donated to ASF
On Sat, Mar 25, 2017 at 17:18 Tom Browder wrote: ... > When I compiled apache2 I used the following config entry > for mod_lua: > > --with-lua=/usr The reasons I did that were: + No clear description in the docs about what path is needed. + I repetitively changed the path based on what the config error told me until I got a clean build and a mod_lua.so. The messages I was getting were that the system could not find file lua.h. Does it need the complete path to the lua interpreter? Or its directory? Or the lua library? Or some kind of pkg-config incantation? -Tom
Re: server-status script donated to ASF
On Mon, Mar 20, 2017 at 07:57 Daniel Gruno wrote: > > On 03/20/2017 01:56 PM, Jim Jagielski wrote: > > Cool... URL? > > https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/ I'm trying to incorporate that script into one of my virtual servers but am getting an error. I'm using apache 2.4.25 and compiled it on Debian 8, 64-bit, Linux, with lua installed using the following Debian packages: i A liblua5.2-0 - Shared library for the Lua interpreter ver i liblua5.2-dev - Development files for the Lua language ver i lua5.2 - Simple, extensible, embeddable programming When I compiled apache2 I used the following config entry for mod_lua: --with-lua=/usr In my httpd.conf file in one of my virtual host directives I entered the following line: LuaMapHandler ^/server-status$ /server-status.lua When I attempt to access server-status at <https://usafa-1965.org/server-status> I get the following error in my browser: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log. The error log shows: [Sat Mar 25 16:49:56.654507 2017] [lua:error] [pid 17864:tid 139883896727296] AH01482: Error loading /server-status.lua: cannot open /server-status.lua: No such file or directory [Sat Mar 25 16:49:56.654518 2017] [lua:crit] [pid 17864:tid 139883896727296] [client 76.3.2.56:54332] AH02330: lua: Failed to obtain Lua interpreter for entry function 'handle' in /server-status.lua I also tried this line in the httpd.conf: and got essentially the same results. From the error log: [Sat Mar 25 17:05:15.460393 2017] [lua:error] [pid 10792:tid 139883913512704] AH01482: Error loading /https:/usafa-1965.org/server-status.lua: cannot open /https:/usafa-1965.org/server-status.lua: No such file or directory [Sat Mar 25 17:05:15.460406 2017] [lua:crit] [pid 10792:tid 139883913512704] [client 76.3.2.56:54364] AH02330: lua: Failed to obtain Lua interpreter for entry function 'handle' in https://usafa-1965.org/server-status.lua In both cases the file actually exists. I suspect the problem is in the config file, but that's just a guess. Any ideas? Thanks. Best regards, -Tom
Re: server-status script donated to ASF
Hi,
when running, the page get longer 5 seconds or so.
In the JS code, there is:
// resize pane
document.getElementById('leftpane').style.height =
document.getElementById('wrapper').getBoundingClientRect().height + "px";
I guess that is "growing page" is coming from there.
What it is used for?
CJ
Le 20/03/2017 à 14:01, Daniel Gruno a écrit :
On 03/20/2017 02:01 PM, Jim Jagielski wrote:
Since these are docs, does that mean they can be
CTR'ed into 2.4? :)
probably? :) it's just an example script, nothing that needs compiling
or counts as de facto replacement yet :)
On Mar 20, 2017, at 8:57 AM, Daniel Gruno wrote:
On 03/20/2017 01:56 PM, Jim Jagielski wrote:
Cool... URL?
https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/
On Mar 15, 2017, at 10:23 AM, Daniel Gruno wrote:
FWIW, the stuff that powers https://httpd.apache.org/server-status has
now been donated to the HTTPd project.
With regards,
Daniel.
Re: server-status script donated to ASF
On 03/20/2017 02:01 PM, Jim Jagielski wrote: > Since these are docs, does that mean they can be > CTR'ed into 2.4? :) probably? :) it's just an example script, nothing that needs compiling or counts as de facto replacement yet :) > >> On Mar 20, 2017, at 8:57 AM, Daniel Gruno wrote: >> >> On 03/20/2017 01:56 PM, Jim Jagielski wrote: >>> Cool... URL? >> >> https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/ >> >>> >>>> On Mar 15, 2017, at 10:23 AM, Daniel Gruno wrote: >>>> >>>> FWIW, the stuff that powers https://httpd.apache.org/server-status has >>>> now been donated to the HTTPd project. >>>> >>>> With regards, >>>> Daniel. >>> >> >
Re: server-status script donated to ASF
Since these are docs, does that mean they can be CTR'ed into 2.4? :) > On Mar 20, 2017, at 8:57 AM, Daniel Gruno wrote: > > On 03/20/2017 01:56 PM, Jim Jagielski wrote: >> Cool... URL? > > https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/ > >> >>> On Mar 15, 2017, at 10:23 AM, Daniel Gruno wrote: >>> >>> FWIW, the stuff that powers https://httpd.apache.org/server-status has >>> now been donated to the HTTPd project. >>> >>> With regards, >>> Daniel. >> >
Re: server-status script donated to ASF
On 03/20/2017 01:56 PM, Jim Jagielski wrote: > Cool... URL? https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/ > >> On Mar 15, 2017, at 10:23 AM, Daniel Gruno wrote: >> >> FWIW, the stuff that powers https://httpd.apache.org/server-status has >> now been donated to the HTTPd project. >> >> With regards, >> Daniel. >
Re: server-status script donated to ASF
Cool... URL? > On Mar 15, 2017, at 10:23 AM, Daniel Gruno wrote: > > FWIW, the stuff that powers https://httpd.apache.org/server-status has > now been donated to the HTTPd project. > > With regards, > Daniel.
Re: server-status script donated to ASF
Very cool! Thanks to all involved! > Am 15.03.2017 um 15:23 schrieb Daniel Gruno : > > FWIW, the stuff that powers https://httpd.apache.org/server-status has > now been donated to the HTTPd project. > > With regards, > Daniel. Stefan Eissing bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
server-status script donated to ASF
FWIW, the stuff that powers https://httpd.apache.org/server-status has now been donated to the HTTPd project. With regards, Daniel.
Re: ACC field in server-status
On Tue, Jan 24, 2017 at 6:38 PM, Eric Covener wrote: > I have been staring at some different /server-status output lately and > notice that the last two fields in ACC are always the same, even > though one is supposed to be connections by slot and the other > connections by process. > >> Number of accesses this connection / this child / this slot > > mod_status is fishing both out of a ws_record, and ap_increment_counts > doesn't seem to go outside of ws_record either to increment anything. > > Putting aside what connections-per-slot even would mean for event, > does anyone recall how/why things are the way they are? Even a 1.3 / > preform-ism wouldn't explain this child / this slot. > > I'm not sure if there's much value in either 'C' field of ACC. I could > see value in the per-process total, but this is the value we're not > actually displaying -- and it's silly to list it in every slot for the > process. > Apparently works differently on some servers, but the conns-this-child still doesn't match across a child. https://paste.apache.org/p/BHMu
ACC field in server-status
I have been staring at some different /server-status output lately and notice that the last two fields in ACC are always the same, even though one is supposed to be connections by slot and the other connections by process. > Number of accesses this connection / this child / this slot mod_status is fishing both out of a ws_record, and ap_increment_counts doesn't seem to go outside of ws_record either to increment anything. Putting aside what connections-per-slot even would mean for event, does anyone recall how/why things are the way they are? Even a 1.3 / preform-ism wouldn't explain this child / this slot. I'm not sure if there's much value in either 'C' field of ACC. I could see value in the per-process total, but this is the value we're not actually displaying -- and it's silly to list it in every slot for the process. -- Eric Covener cove...@gmail.com
Fwd: [users@httpd] Looking for a new maintainer for FableTech Server Status for Apache
Dev list is probably a better place to ask this. -- Forwarded message -- From: Morten Shearman Kirkegaard Date: Tue, Feb 17, 2015 at 1:37 PM Subject: [users@httpd] Looking for a new maintainer for FableTech Server Status for Apache To: us...@httpd.apache.org Hi list, A few years ago FableTech developed a tool which allows a sysadm to see what his Apache httpd is serving, even if the server-status page is not responding. It's relatively simple, but can be very useful. Going forward we will not be able to maintain the project, so we are looking for somebody to take over. Perhaps the Apache Software Foundation would be interested in taking over this tiny project? More information about the project: http://fabletech.com/ftss Kind regards, Morten - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Cool. On Sep 12, 2014, at 8:57 AM, Martynas Bendorius wrote: > Super! I've tested it and it solves all the problems with mod_status. Thank > you. > > Best regards, > Martynas Bendorius > > On 9/12/14 3:46 PM, Jim Jagielski wrote: >> Fixed in: >> >> http://svn.apache.org/r1624349 >> >> On Sep 11, 2014, at 12:23 PM, Jim Jagielski wrote: >> >>> Well, fixing this *specifically* for mod_status is >>> easy, but, as you say, the problem is more systemic >>> than that. >>> >>> On Sep 11, 2014, at 12:13 PM, wr...@rowe-clan.net wrote: >>> >>>> - Original Message - >>>> Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) >>>> on server-status page >>>> From: "Jim Jagielski" >>>> Date: 9/11/14 10:45 am >>>> To: dev@httpd.apache.org >>>> >>>> Ugg. Yeah; we should actually have a complimentary version >>>> that takes request_req as the param, not conn_rec. >>>> >>>> ap_get_remote_host_r()?? >>>> >>>> Considered that. But that still breaks mod_remoteip's advertised >>>> behavior against third party modules until they adapt. So I'd written >>>> this off as a non-starter :( >>>> >>>> Ugly. >>>> >>>> Indeed >>> >> >
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Super! I've tested it and it solves all the problems with mod_status. Thank you. Best regards, Martynas Bendorius On 9/12/14 3:46 PM, Jim Jagielski wrote: Fixed in: http://svn.apache.org/r1624349 On Sep 11, 2014, at 12:23 PM, Jim Jagielski wrote: Well, fixing this *specifically* for mod_status is easy, but, as you say, the problem is more systemic than that. On Sep 11, 2014, at 12:13 PM, wr...@rowe-clan.net wrote: - Original Message - Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page From: "Jim Jagielski" Date: 9/11/14 10:45 am To: dev@httpd.apache.org Ugg. Yeah; we should actually have a complimentary version that takes request_req as the param, not conn_rec. ap_get_remote_host_r()?? Considered that. But that still breaks mod_remoteip's advertised behavior against third party modules until they adapt. So I'd written this off as a non-starter :( Ugly. Indeed
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Fixed in: http://svn.apache.org/r1624349 On Sep 11, 2014, at 12:23 PM, Jim Jagielski wrote: > Well, fixing this *specifically* for mod_status is > easy, but, as you say, the problem is more systemic > than that. > > On Sep 11, 2014, at 12:13 PM, wr...@rowe-clan.net wrote: > >> - Original Message - >> Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) >> on server-status page >> From: "Jim Jagielski" >> Date: 9/11/14 10:45 am >> To: dev@httpd.apache.org >> >> Ugg. Yeah; we should actually have a complimentary version >> that takes request_req as the param, not conn_rec. >> >> ap_get_remote_host_r()?? >> >> Considered that. But that still breaks mod_remoteip's advertised >> behavior against third party modules until they adapt. So I'd written >> this off as a non-starter :( >> >> Ugly. >> >> Indeed >
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Well, fixing this *specifically* for mod_status is easy, but, as you say, the problem is more systemic than that. On Sep 11, 2014, at 12:13 PM, wr...@rowe-clan.net wrote: > - Original Message - > Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on > server-status page > From: "Jim Jagielski" > Date: 9/11/14 10:45 am > To: dev@httpd.apache.org > > Ugg. Yeah; we should actually have a complimentary version > that takes request_req as the param, not conn_rec. > > ap_get_remote_host_r()?? > > Considered that. But that still breaks mod_remoteip's advertised > behavior against third party modules until they adapt. So I'd written > this off as a non-starter :( > > Ugly. > > Indeed
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Am 11.09.2014 um 18:13 schrieb wr...@rowe-clan.net: > Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not > useragent_ip) on server-status page > From: "Jim Jagielski" > Date: 9/11/14 10:45 am > To: dev@httpd.apache.org > > Ugg. Yeah; we should actually have a complimentary version > that takes request_req as the param, not conn_rec. > > ap_get_remote_host_r()?? > > Considered that. But that still breaks mod_remoteip's advertised > behavior against third party modules until they adapt. So I'd written > this off as a non-starter :( yes - please don't break mod_security! it took me hours of discussions to bring developers to make it Apache 2.4 compliant and not enforce users to use the unstrusted "forwarded for" headers not caring about the connection IP if there needs now to be a change because 2.4.10 behaves different as a following release it becomes hard to handle signature.asc Description: OpenPGP digital signature
RE: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
- Original Message - Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page From: "Jim Jagielski" Date: 9/11/14 10:45 am To: dev@httpd.apache.org Ugg. Yeah; we should actually have a complimentary version that takes request_req as the param, not conn_rec. ap_get_remote_host_r()?? Considered that. But that still breaks mod_remoteip's advertised behavior against third party modules until they adapt. So I'd written this off as a non-starter :( Ugly. Indeed
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Ugg. Yeah; we should actually have a complimentary version that takes request_req as the param, not conn_rec. ap_get_remote_host_r()?? Ugly. On Sep 11, 2014, at 11:28 AM, wr...@rowe-clan.net wrote: > However, the API is not going to make this trivial to fix. > > ap_get_remote_host is connection-based. And that is what mod_authz_host > is currently relying upon. > > It seems that there needs to be a way for mod_remoteip to override the > existing behavior, perhaps ap_set_remote_host(), that will cache the > request-based on for the lifetime of the request pool. In the request > pool cleanup, ap_set_remote_host(c, NULL) would clear that overridden > request-based host, popping the value back to the cached c-> fields. > > There is also the issue of the timing of setting the scoreboard record. > All three issues are intertwined. > > > - Original Message - > Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on > server-status page > From: "Jim Jagielski" > Date: 9/11/14 9:46 am > To: dev@httpd.apache.org > > Yeah, the more I think about it, ap_get_remote_host() is > currently broken wrt how it handles useragent_ip and client_ip. > > Will likely try to patch this on trunk sometime today... > > On Sep 11, 2014, at 9:35 AM, Martynas Bendorius wrote: > > > Yes, we may re-phrase it like that, if we'd like to fix it in apache source > > (and not documentation) :) Currently ap_get_remote_host in server/core.c > > doesn't return useragent_ip, and instead of it we get conn->client_ip. > > > > Best regards, > > Martynas Bendorius > > > > On 9/11/14 4:21 PM, Jim Jagielski wrote: > >> isn't the question rather "What should ap_get_remote_host() > >> return?"? > >> > >> On Sep 11, 2014, at 8:17 AM, Martynas Bendorius > >> wrote: > >> > >>> Hello, > >>> > >>> Would it be possible to change the documentation of mod_remoteip for 2.4 > >>> (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is > >>> reported by mod_status" removed from the page? As it leds Apache > >>> customers to believe that it will report a real (useragent) IP instead of > >>> a proxy one in server-status page. useragent_ip is not even available in > >>> scoreboard, which is used by mod_status, so it's not available for > >>> mod_status. > >>> > >>> This has been already discussed here: > >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 > >>> > >>> Thank you! > >>> > >>> Best regards, > >>> Martynas Bendorius > >>> > >> > >
RE: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
However, the API is not going to make this trivial to fix. ap_get_remote_host is connection-based. And that is what mod_authz_host is currently relying upon. It seems that there needs to be a way for mod_remoteip to override the existing behavior, perhaps ap_set_remote_host(), that will cache the request-based on for the lifetime of the request pool. In the request pool cleanup, ap_set_remote_host(c, NULL) would clear that overridden request-based host, popping the value back to the cached c-> fields. There is also the issue of the timing of setting the scoreboard record. All three issues are intertwined. - Original Message - Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page From: "Jim Jagielski" Date: 9/11/14 9:46 am To: dev@httpd.apache.org Yeah, the more I think about it, ap_get_remote_host() is currently broken wrt how it handles useragent_ip and client_ip. Will likely try to patch this on trunk sometime today... On Sep 11, 2014, at 9:35 AM, Martynas Bendorius wrote: > Yes, we may re-phrase it like that, if we'd like to fix it in apache source > (and not documentation) :) Currently ap_get_remote_host in server/core.c > doesn't return useragent_ip, and instead of it we get conn->client_ip. > > Best regards, > Martynas Bendorius > > On 9/11/14 4:21 PM, Jim Jagielski wrote: >> isn't the question rather "What should ap_get_remote_host() >> return?"? >> >> On Sep 11, 2014, at 8:17 AM, Martynas Bendorius >> wrote: >> >>> Hello, >>> >>> Would it be possible to change the documentation of mod_remoteip for 2.4 >>> (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is >>> reported by mod_status" removed from the page? As it leds Apache customers >>> to believe that it will report a real (useragent) IP instead of a proxy >>> one in server-status page. useragent_ip is not even available in >>> scoreboard, which is used by mod_status, so it's not available for >>> mod_status. >>> >>> This has been already discussed here: >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 >>> >>> Thank you! >>> >>> Best regards, >>> Martynas Bendorius >>> >> >
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Yeah, the more I think about it, ap_get_remote_host() is currently broken wrt how it handles useragent_ip and client_ip. Will likely try to patch this on trunk sometime today... On Sep 11, 2014, at 9:35 AM, Martynas Bendorius wrote: > Yes, we may re-phrase it like that, if we'd like to fix it in apache source > (and not documentation) :) Currently ap_get_remote_host in server/core.c > doesn't return useragent_ip, and instead of it we get conn->client_ip. > > Best regards, > Martynas Bendorius > > On 9/11/14 4:21 PM, Jim Jagielski wrote: >> isn't the question rather "What should ap_get_remote_host() >> return?"? >> >> On Sep 11, 2014, at 8:17 AM, Martynas Bendorius wrote: >> >>> Hello, >>> >>> Would it be possible to change the documentation of mod_remoteip for 2.4 >>> (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is >>> reported by mod_status" removed from the page? As it leds Apache customers >>> to believe that it will report a real (useragent) IP instead of a proxy one >>> in server-status page. useragent_ip is not even available in scoreboard, >>> which is used by mod_status, so it's not available for mod_status. >>> >>> This has been already discussed here: >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 >>> >>> Thank you! >>> >>> Best regards, >>> Martynas Bendorius >>> >> >
RE: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
+1, this is the right question, Jim. >From the docs for mod_remoteip; "This module is used to treat the useragent which initiated the request as the originating useragent as identified by httpd for the purposes of authorization and logging" "The module overrides the client IP address for the connection" "Once replaced as instructed, this overridden useragent IP address is then used" Any other behavior is invalid to users of mod_remoteip. It was correctly observed that there is an intermediate state, following the logging of a request and destruction of the request pool, where the identity of the keep-alive connection truly belongs to the direct-remote user agent, and is no longer an attribute of the proxied request. Therefore, falling back to the c->remote_addr is entirely appropriate, and that remote_addr must be used as the basis for mod_remoteip to handshake the next reported remote client ip. So here's a +1 to changing the behavior of ap_get_remote_host, as documented, the existing behavior is flawed. - Original Message - Subject: Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page From: "Martynas Bendorius" Date: 9/11/14 8:35 am To: dev@httpd.apache.org Yes, we may re-phrase it like that, if we'd like to fix it in apache source (and not documentation) :) Currently ap_get_remote_host in server/core.c doesn't return useragent_ip, and instead of it we get conn->client_ip. Best regards, Martynas Bendorius On 9/11/14 4:21 PM, Jim Jagielski wrote: > isn't the question rather "What should ap_get_remote_host() > return?"? > > On Sep 11, 2014, at 8:17 AM, Martynas Bendorius wrote: > >> Hello, >> >> Would it be possible to change the documentation of mod_remoteip for 2.4 >> (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is >> reported by mod_status" removed from the page? As it leds Apache customers >> to believe that it will report a real (useragent) IP instead of a proxy one >> in server-status page. useragent_ip is not even available in scoreboard, >> which is used by mod_status, so it's not available for mod_status. >> >> This has been already discussed here: >> https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 >> >> Thank you! >> >> Best regards, >> Martynas Bendorius >> >
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Yes, we may re-phrase it like that, if we'd like to fix it in apache source (and not documentation) :) Currently ap_get_remote_host in server/core.c doesn't return useragent_ip, and instead of it we get conn->client_ip. Best regards, Martynas Bendorius On 9/11/14 4:21 PM, Jim Jagielski wrote: isn't the question rather "What should ap_get_remote_host() return?"? On Sep 11, 2014, at 8:17 AM, Martynas Bendorius wrote: Hello, Would it be possible to change the documentation of mod_remoteip for 2.4 (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is reported by mod_status" removed from the page? As it leds Apache customers to believe that it will report a real (useragent) IP instead of a proxy one in server-status page. useragent_ip is not even available in scoreboard, which is used by mod_status, so it's not available for mod_status. This has been already discussed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 Thank you! Best regards, Martynas Bendorius
Re: mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
isn't the question rather "What should ap_get_remote_host() return?"? On Sep 11, 2014, at 8:17 AM, Martynas Bendorius wrote: > Hello, > > Would it be possible to change the documentation of mod_remoteip for 2.4 > (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is > reported by mod_status" removed from the page? As it leds Apache customers to > believe that it will report a real (useragent) IP instead of a proxy one in > server-status page. useragent_ip is not even available in scoreboard, which > is used by mod_status, so it's not available for mod_status. > > This has been already discussed here: > https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 > > Thank you! > > Best regards, > Martynas Bendorius >
mod_status: Apache 2.4 incorrect IP (proxy, not useragent_ip) on server-status page
Hello, Would it be possible to change the documentation of mod_remoteip for 2.4 (http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html), and get "is reported by mod_status" removed from the page? As it leds Apache customers to believe that it will report a real (useragent) IP instead of a proxy one in server-status page. useragent_ip is not even available in scoreboard, which is used by mod_status, so it's not available for mod_status. This has been already discussed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=55886 Thank you! Best regards, Martynas Bendorius
Re: Apache 2.4 - incorrect (proxy, but not user) IP on server-status page
On 17 Aug 2014, at 22:34, Martynas Bendorius wrote: > Would anyone be willing to review > https://issues.apache.org/bugzilla/attachment.cgi?id=31706&action=diff and > merge it to the trunk if it looks fine? It changes connection->client_ip to > useragent_ip in scoreboard, so it might affect some other things, however > that seems to be the only smart way for now to fix the bug. Swapping the one IP for the other is definitely the wrong way to go about this. Apache supports both the client and remote IP addresses as first class concepts, the real fix for this is to add the missing IP to the scoreboard. Regards, Graham --
Apache 2.4 - incorrect (proxy, but not user) IP on server-status page
Hello, Would anyone be willing to review https://issues.apache.org/bugzilla/attachment.cgi?id=31706&action=diff and merge it to the trunk if it looks fine? It changes connection->client_ip to useragent_ip in scoreboard, so it might affect some other things, however that seems to be the only smart way for now to fix the bug. Thank you! -- Best regards, Martynas Bendorius
Re: 2.4.3 running on mail-archives us / server-status problem
On 17.11.2012 22:12, Rainer Jung wrote: > Hi, > > I updated the first ASF web server from 2.4.1 to 2.4.3. It is running > the service for mail-archives.apache.org in US, so you can reach it via > mail-archives.us.apache.org. It is being proxied by www.apache.org. > > One strange thing: the /server-status directly tells us it has about 80 > process running (it is prefork MPM), but after the fifth entry in the > extended status part the table stops. It seems the iteration through the > scoreboard is incomplete. > > Anyone ever has seen this? Source indicates that this is due to access count on those processes being 0. Since traffic on that one isn't to high and CPU in fact is 0 on all but these 5 processes, this seems to be a consistent explanation. Regards, Rainer
2.4.3 running on mail-archives us / server-status problem
Hi, I updated the first ASF web server from 2.4.1 to 2.4.3. It is running the service for mail-archives.apache.org in US, so you can reach it via mail-archives.us.apache.org. It is being proxied by www.apache.org. One strange thing: the /server-status directly tells us it has about 80 process running (it is prefork MPM), but after the fifth entry in the extended status part the table stops. It seems the iteration through the scoreboard is incomplete. Anyone ever has seen this? Will have a look at the code ... Regards, Rainer
Re: Server Status Client IP
On 10 May 2012, at 8:13 PM, Steffen wrote: > Running a reverse proxy in front of Apache 2.4.2 (known reason, to get more > reliable networking in Windows). > > The proxy supplies the X-Forwarded-For header and using in Apache: > LoadModule remoteip_module modules/mod_remoteip.so > RemoteIPHeader X-Forwarded-For > > The mod-status page gives as client IP, the reverse proxy IP. > The access log gives the good client/remote IP. > > Is this by design ? In the case of the access_log, yes. There are two separate variables representing each IP address, configure the access_log template as appropriate for your needs. Ideally the mod_status page should give you both IPs, not sure if that is configurable at this point. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Server Status Client IP
Running a reverse proxy in front of Apache 2.4.2 (known reason, to get more reliable networking in Windows). The proxy supplies the X-Forwarded-For header and using in Apache: LoadModule remoteip_module modules/mod_remoteip.so RemoteIPHeader X-Forwarded-For The mod-status page gives as client IP, the reverse proxy IP. The access log gives the good client/remote IP. Is this by design ? Steffen
Re: ******** Interesting server-status at w.a.o
On 26.02.2012 17:46, Sander Temme wrote: On Feb 24, 2012, at 3:50 AM, Rainer Jung wrote: On 24.02.2012 12:12, Steffen wrote: Looks like the hanging "L"'s, which I reported way back, which was investigated by Stefan Could be but not necessarily. It depends on your MaxConnectionsPerChild setting. The situation at w.a.o is due to processes getting recycled. I sporadically watched the server-status there and the "L" situation did not show up for a long time. I expect the adminds did restart Apache gracefully. If I recall correctly, a.o httpds get a Graceful every 24h to turn over the logs. So you should never see a really long-lived scoreboard on any of those instances. Yes, Daniel Shahaf also wrote on the infra list, that they have a daily restart. But the problem seems to happen often enough, e.g. today you can see the same symptoms. I even saw for a few seconds a server-status that had all processes with a "no" in the "accepting" column (although I could still get the result of the server-status itself. Nevertheless still it is still version 2.3.15 I hope we will see something better after infra finds time to update. Regards, Rainer
Re: ******** Interesting server-status at w.a.o
On Feb 24, 2012, at 3:50 AM, Rainer Jung wrote: > On 24.02.2012 12:12, Steffen wrote: >> Looks like the hanging "L"'s, which I reported way back, which was >> investigated by Stefan > > Could be but not necessarily. It depends on your MaxConnectionsPerChild > setting. The situation at w.a.o is due to processes getting recycled. I > sporadically watched the server-status there and the "L" situation did not > show up for a long time. I expect the adminds did restart Apache gracefully. If I recall correctly, a.o httpds get a Graceful every 24h to turn over the logs. So you should never see a really long-lived scoreboard on any of those instances. S. -- scte...@apache.orghttp://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme
Re: Interesting server-status at w.a.o
On Friday 24 February 2012, Rainer Jung wrote: > > Looks like the hanging "L"'s, which I reported way back, which > > was investigated by Stefan > > > But maybe that's also fixed with Stefan's "L" improvements. Didn't > have time to check it. I hope infra will update to 2.4.1. I can't remember having made any change directly relevant to the hanging "L" states. I only fixed various other logging issues found by Steffen. But the changes from w.a.o's version to 2.4.1 are so large that it makes sense to update w.a.o first and investigate the problems afterwards.
Re: ******** Interesting server-status at w.a.o
On 24.02.2012 12:12, Steffen wrote: Looks like the hanging "L"'s, which I reported way back, which was investigated by Stefan Could be but not necessarily. It depends on your MaxConnectionsPerChild setting. The situation at w.a.o is due to processes getting recycled. I sporadically watched the server-status there and the "L" situation did not show up for a long time. I expect the adminds did restart Apache gracefully. If your "L"s showed up during normal operation without restart and with MaxConnectionsPerChild 0, then it could well be totaly unrelated. If they suddenly show up when your child is being recycled, then it could be the same reason. > With 2.4.1, I have not seeing the "L"'s (yet). > That's good to know. Thanks! The more important problem at w.a.o IMHO is that those gracefully shutting down processes either do not terminate, or their scoreboard entries are not cleared. But maybe that's also fixed with Stefan's "L" improvements. Didn't have time to check it. I hope infra will update to 2.4.1. Regards, Rainer
Re: ******** Interesting server-status at w.a.o
Looks like the hanging "L"'s, which I reported way back, which was investigated by Stefan With 2.4.1, I have not seeing the "L"'s (yet). -Original Message- From: Rainer Jung Sent: Friday, February 24, 2012 11:59 AM To: dev@httpd.apache.org Cc: Apache Infrastructure Subject: Interesting server-status at w.a.o Currently server-status at w.a.o shows 4 processes with no busy requests but all slots in state "G" or "L" and many connections in "closing". It seems the reason for those processes to not end are the closing connections, but if it were correct lingering close, that would have ended long ago. The situation persists since at least 10 minutes now, so those recycling processes seem to hang. In addition it is strange, that we see many "L" slots for those gracefully shutting down processes. Looks like the state reset after "L" doesn't happen when a process is scheduled for recycling. Note that w.a.o is still at 2.3.15. Don't know whether we can get some thread stacks for the hanging PIDs 69762, 62850, 62438 and 63707. Regards, Rainer
Interesting server-status at w.a.o
Currently server-status at w.a.o shows 4 processes with no busy requests but all slots in state "G" or "L" and many connections in "closing". It seems the reason for those processes to not end are the closing connections, but if it were correct lingering close, that would have ended long ago. The situation persists since at least 10 minutes now, so those recycling processes seem to hang. In addition it is strange, that we see many "L" slots for those gracefully shutting down processes. Looks like the state reset after "L" doesn't happen when a process is scheduled for recycling. Note that w.a.o is still at 2.3.15. Don't know whether we can get some thread stacks for the hanging PIDs 69762, 62850, 62438 and 63707. Regards, Rainer
Re: Win 2.3.16 :: Server Status Entries
Ok, I should have been more exact EnableMMAP off + EnableSendfile Off ---> L status stays EnableMMAP off + EnableSendfile On ---> normal behaviour EnableMMAP on + EnableSendfile On ---> normal behaviour EnableMMAP on + EnableSendfile Off ---> normal behaviour Mario On Wed, Jan 4, 2012 at 11:37, Rainer Jung wrote: > On 04.01.2012 11:02, Mario Brandt wrote: >> >> I figured out that using EnableMMAP off causes the L status. I tried >> it in combination with EnableSendfile off and without. > > > By "without" you mean "EnableSendfile On" or just default? Note that the > default for EnableSendfile is again "Off" in 2.4, so it is expected we don't > see a difference between Off and default. > > >> I hope that helps finding the error. > > > Thanks, > > Rainer > > >> On Sat, Dec 31, 2011 at 21:08, Steffen wrote: >>>> >>>> That's not expected. Can any Windows Seniors comment on that? Why could >>>> we >>>> have the Logging status in server-status for a long time for the winnt >>>> MPM? >>> >>> >>> >>> This bug is still there in 2.3.16, have "L" entries for more then a week >>> ! >>> They are occupying workers all the time, so the busyorkers are far high: >>> >>> L__L_L___LL_L__L___L_L_L__ >>> >>> >>> Happy (2.4) new year to all, >>> Steffen >>> >>> -Original Message- From: Rainer Jung >>> Sent: Tuesday, December 06, 2011 9:33 PM Newsgroups: >>> gmane.comp.apache.devel >>> To: dev@httpd.apache.org >>> Subject: Re: Win 2.3.15 :: Server Status Entries >>> >>> On 06.12.2011 11:56, Steffen wrote: >>>>> >>>>> >>>>> Those requests are no longer processed (status is "_"). The seconds >>>>> since is the time since this request was last processed, the column >>>>> after that shows how long processing took (here: "1" millisecond for >>>>> each of them). >>>> >>>> >>>> >>>> There are also with status L, for example for almost a day sitting >>>> there: >>>> >>>> 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 >>>> www.apachelounge.com GET >>>> /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 >>> >>> >>> >>> That's not expected. Can any Windows Seniors comment on that? Why could >>> we have the Logging status in server-status for a long time for the >>> winnt MPM? >>> >>>> -Original Message- From: Rainer Jung >>>> Sent: Tuesday, November 22, 2011 11:32 AM >>>> To: dev@httpd.apache.org >>>> Subject: Re: Win 2.3.15 :: Server Status Entries >>>> >>>> On 22.11.2011 10:28, Steffen wrote: >>>>> >>>>> >>>>> Seeing a huge number of hanging entries in the Server Status, >>>>> already for 20 hours and looks they are staying there forever. >>>>> >>>>> The requests are invalid, not sure since I do not keep the raw logs. >>>>> >>>>> ... >>>>> ... >>>>> 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 >>>>> www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 >>>>> 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 >>>>> www.familieland.com GET //scripts/setup.php HTTP/1.1 >>>>> 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 >>>>> www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 >>>>> >>>>> >>>>> etc. etc. >>>>> >>>>> SS = 70878 seconds now and counting. >>>> >>>> >>>> >>>> Those requests are no longer processed (status is "_"). The seconds >>>> since is the time since this request was last processed, the column >>>> after that shows how long processing took (here: "1" millisecond for >>>> each of them). >>>> >>>> It looks like you have spare slots that are occasionally used during >>>> load spikes but are idle later for a long time. Don't know how the >>>> Windows MPM decides which idle slot to use. >>>> >>>> Regards, >>>> >>>> Rainer >>> >>> >>> >> >
Re: Win 2.3.16 :: Server Status Entries
On 04.01.2012 11:02, Mario Brandt wrote: I figured out that using EnableMMAP off causes the L status. I tried it in combination with EnableSendfile off and without. By "without" you mean "EnableSendfile On" or just default? Note that the default for EnableSendfile is again "Off" in 2.4, so it is expected we don't see a difference between Off and default. I hope that helps finding the error. Thanks, Rainer On Sat, Dec 31, 2011 at 21:08, Steffen wrote: That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? This bug is still there in 2.3.16, have "L" entries for more then a week ! They are occupying workers all the time, so the busyorkers are far high: L__L_L___LL_L__L___L_L_L__ Happy (2.4) new year to all, Steffen -Original Message- From: Rainer Jung Sent: Tuesday, December 06, 2011 9:33 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 06.12.2011 11:56, Steffen wrote: Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). There are also with status L, for example for almost a day sitting there: 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 www.apachelounge.com GET /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? -Original Message- From: Rainer Jung Sent: Tuesday, November 22, 2011 11:32 AM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Re: Win 2.3.16 :: Server Status Entries
I figured out that using EnableMMAP off causes the L status. I tried it in combination with EnableSendfile off and without. I hope that helps finding the error. Greetz Mario On Sat, Dec 31, 2011 at 21:08, Steffen wrote: >> That's not expected. Can any Windows Seniors comment on that? Why could we >> have the Logging status in server-status for a long time for the winnt >> MPM? > > > This bug is still there in 2.3.16, have "L" entries for more then a week ! > They are occupying workers all the time, so the busyorkers are far high: > > L__L_L___LL_L__L___L_L_L__ > > > Happy (2.4) new year to all, > Steffen > > -Original Message- From: Rainer Jung > Sent: Tuesday, December 06, 2011 9:33 PM Newsgroups: gmane.comp.apache.devel > To: dev@httpd.apache.org > Subject: Re: Win 2.3.15 :: Server Status Entries > > On 06.12.2011 11:56, Steffen wrote: >>> >>> Those requests are no longer processed (status is "_"). The seconds >>> since is the time since this request was last processed, the column >>> after that shows how long processing took (here: "1" millisecond for >>> each of them). >> >> >> There are also with status L, for example for almost a day sitting there: >> >> 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 >> www.apachelounge.com GET >> /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 > > > That's not expected. Can any Windows Seniors comment on that? Why could > we have the Logging status in server-status for a long time for the > winnt MPM? > >> -Original Message- From: Rainer Jung >> Sent: Tuesday, November 22, 2011 11:32 AM >> To: dev@httpd.apache.org >> Subject: Re: Win 2.3.15 :: Server Status Entries >> >> On 22.11.2011 10:28, Steffen wrote: >>> >>> Seeing a huge number of hanging entries in the Server Status, >>> already for 20 hours and looks they are staying there forever. >>> >>> The requests are invalid, not sure since I do not keep the raw logs. >>> >>> ... >>> ... >>> 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 >>> www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 >>> 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 >>> www.familieland.com GET //scripts/setup.php HTTP/1.1 >>> 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 >>> www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 >>> >>> >>> etc. etc. >>> >>> SS = 70878 seconds now and counting. >> >> >> Those requests are no longer processed (status is "_"). The seconds >> since is the time since this request was last processed, the column >> after that shows how long processing took (here: "1" millisecond for >> each of them). >> >> It looks like you have spare slots that are occasionally used during >> load spikes but are idle later for a long time. Don't know how the >> Windows MPM decides which idle slot to use. >> >> Regards, >> >> Rainer > >
Re: Win 2.3.16 :: Server Status Entries
Maybe a clue: Seems to happen when there is an error. For example during Partial Downloading (206) [http:error] [pid 3244:tid 2656] (70007)The timeout specified has expired: [client 114.79.60.32:11091] Timeout while writing data for URI /download/binaries/httpd-2.2.21-win32.zip to the client -Original Message- From: Steffen Sent: Saturday, December 31, 2011 9:08 PM To: dev@httpd.apache.org Subject: Re: Win 2.3.16 :: Server Status Entries That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? This bug is still there in 2.3.16, have "L" entries for more then a week ! They are occupying workers all the time, so the busyorkers are far high: L__L_L___LL_L__L___L_L_L__ Happy (2.4) new year to all, Steffen -Original Message- From: Rainer Jung Sent: Tuesday, December 06, 2011 9:33 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 06.12.2011 11:56, Steffen wrote: Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). There are also with status L, for example for almost a day sitting there: 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 www.apachelounge.com GET /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? -Original Message- From: Rainer Jung Sent: Tuesday, November 22, 2011 11:32 AM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Re: Win 2.3.16 :: Server Status Entries
That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? This bug is still there in 2.3.16, have "L" entries for more then a week ! They are occupying workers all the time, so the busyorkers are far high: L__L_L___LL_L__L___L_L_L__ Happy (2.4) new year to all, Steffen -Original Message- From: Rainer Jung Sent: Tuesday, December 06, 2011 9:33 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 06.12.2011 11:56, Steffen wrote: Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). There are also with status L, for example for almost a day sitting there: 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 www.apachelounge.com GET /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? -Original Message- From: Rainer Jung Sent: Tuesday, November 22, 2011 11:32 AM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Re: Win 2.3.15 :: Server Status Entries
Update: that one with a L is gone after ~33 hours -Original Message- From: Rainer Jung Sent: Tuesday, December 06, 2011 9:33 PM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 06.12.2011 11:56, Steffen wrote: Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). There are also with status L, for example for almost a day sitting there: 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 www.apachelounge.com GET /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? -Original Message- From: Rainer Jung Sent: Tuesday, November 22, 2011 11:32 AM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Re: Win 2.3.15 :: Server Status Entries
On 06.12.2011 11:56, Steffen wrote: Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). There are also with status L, for example for almost a day sitting there: 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 www.apachelounge.com GET /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 That's not expected. Can any Windows Seniors comment on that? Why could we have the Logging status in server-status for a long time for the winnt MPM? -Original Message- From: Rainer Jung Sent: Tuesday, November 22, 2011 11:32 AM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Re: Win 2.3.15 :: Server Status Entries
Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). There are also with status L, for example for almost a day sitting there: 0-0 2852 1/2920/2920 L 79507 49835 2893.9 114.05 114.05 80.91.181.75 www.apachelounge.com GET /download/binaries/httpd-2.2.21-win32-x86-ssl.zip HTTP/1.0 -Original Message- From: Rainer Jung Sent: Tuesday, November 22, 2011 11:32 AM To: dev@httpd.apache.org Subject: Re: Win 2.3.15 :: Server Status Entries On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Re: Win 2.3.15 :: Server Status Entries
On Tuesday 22 November 2011, Rainer Jung wrote: > On 22.11.2011 10:28, Steffen wrote: > > Seeing a huge number of hanging entries in the Server Status, > > already for 20 hours and looks they are staying there forever. > > > > The requests are invalid, not sure since I do not keep the raw > > logs. > > > > ... > > ... > > 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 > > www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 > > 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 > > www.familieland.com GET //scripts/setup.php HTTP/1.1 > > 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 > > www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 > > > > > > etc. etc. > > > > SS = 70878 seconds now and counting. > > Those requests are no longer processed (status is "_"). The seconds > since is the time since this request was last processed, the column > after that shows how long processing took (here: "1" millisecond > for each of them). With MPM event, the SS column does not increase for unused slots. Maybe this is actually a bug in the windows mpm? > It looks like you have spare slots that are occasionally used > during load spikes but are idle later for a long time. Don't know > how the Windows MPM decides which idle slot to use. > > Regards, > > Rainer
Re: Win 2.3.15 :: Server Status Entries
After almost 2 days a huge amount hanging entries are still there. Going to stop/start Apache From: Steffen Sent: Tuesday, November 22, 2011 10:28 AM To: dev@httpd.apache.org Subject: Win 2.3.15 :: Server Status Entries Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting.
Re: Win 2.3.15 :: Server Status Entries
On 22.11.2011 10:28, Steffen wrote: Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting. Those requests are no longer processed (status is "_"). The seconds since is the time since this request was last processed, the column after that shows how long processing took (here: "1" millisecond for each of them). It looks like you have spare slots that are occasionally used during load spikes but are idle later for a long time. Don't know how the Windows MPM decides which idle slot to use. Regards, Rainer
Win 2.3.15 :: Server Status Entries
Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting.
Win 2.3.15 :: Server Status Entries
Seeing a huge number of hanging entries in the Server Status, already for 20 hours and looks they are staying there forever. The requests are invalid, not sure since I do not keep the raw logs. ... ... 0-0 3800 0/177/177 _ 64980 1 0.0 0.09 0.09 94.76.244.212 www.familieland.com GET //phpMyAdmin/scripts/setup.php HTTP/1.1 0-0 3800 0/157/157 _ 69024 1 0.0 10.65 10.65 94.76.244.212 www.familieland.com GET //scripts/setup.php HTTP/1.1 0-0 3800 0/224/224 _ 69023 1 0.0 21.96 21.96 94.76.244.212 www.familieland.com GET //admin/pma/scripts/setup.php HTTP/1.1 etc. etc. SS = 70878 seconds now and counting.
[PATCH] (Bug 50555) Added hostname field to the server-status
I've added new field to the server-status. It calls 'Hostname' which show you value of 'Host:' from each request. But I don't know what others thinks about this idea. https://issues.apache.org/bugzilla/show_bug.cgi?id=50555 -- With best regards
Re: server-status and privacy
> There have been a few reports regarding how server-status "leaks" > info, mostly about our (the ASF's) open use of server-status and > how IP addresses are exposed. > > I'm thinking about a patch that adjusts server-status/mod_status > to have a "public vs. private" setting... Public would be to > have IP addresses exposed as public info; private would be to > not expose 'em (keep 'em private). > > Comments? > This is a cool idea! It reminds me of the ability to privatize email addresses when publishing mailing lists as html with something like Monharc. FYI - when I first read your email, I thought you were proposing some sort of ACL keywords for public v. private subnets. -- http://www.docunext.com/
Re: server-status and privacy
On Thu, Jun 24, 2010 at 9:00 AM, Eric Covener wrote: >> A general capability would need to be added to the server to handle >> this situation (e.g., restrict one/all handler adjustment from >> .htaccess when FileInfo can be overridden, or something else >> altogether). > > How about two mod_status directives: > > * option for "ServerStatus ON|OFF" valid in > * a per-server option to only respond to the new flag > > Perhaps with differing defaults for the latter in 2.2 and 2.4 mod_info, mod_anything-activated-via-sethandler
Re: server-status and privacy
> A general capability would need to be added to the server to handle > this situation (e.g., restrict one/all handler adjustment from > .htaccess when FileInfo can be overridden, or something else > altogether). How about two mod_status directives: * option for "ServerStatus ON|OFF" valid in * a per-server option to only respond to the new flag Perhaps with differing defaults for the latter in 2.2 and 2.4 -- Eric Covener cove...@gmail.com
Re: server-status and privacy
On Thu, Jun 24, 2010 at 7:05 AM, g...@schwicking.de wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nick Kew wrote: >> On 22 Jun 2010, at 08:20, g...@schwicking.de wrote: >> >>> Just as a hint: i posted a patch about two weeks ago, >> >> Pointer? Was that somewhere in bugzilla? I don't see it on-list. >> > I have not opened a bug report yet. I was about to, when this thread > started. > > If the outcome of this thread is, that nothing will be done, i will open > a bug report and attach the patch. > > The patch is also attached to this mail for your convinience :-) Configuring the mod_status handler name is no real solution and won't be committed. A general capability would need to be added to the server to handle this situation (e.g., restrict one/all handler adjustment from .htaccess when FileInfo can be overridden, or something else altogether). In the meantime, just edit your mod_status.c to change the handler name and lock down the config and anything that can look at it (filesystem access/mod_perl/mod_info/???).
Re: server-status and privacy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Kew wrote:
> On 22 Jun 2010, at 08:20, g...@schwicking.de wrote:
>
>> Just as a hint: i posted a patch about two weeks ago,
>
> Pointer? Was that somewhere in bugzilla? I don't see it on-list.
>
I have not opened a bug report yet. I was about to, when this thread
started.
If the outcome of this thread is, that nothing will be done, i will open
a bug report and attach the patch.
The patch is also attached to this mail for your convinience :-)
regards
volker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwjPBEACgkQHaTGAGocg2JXggCgtX+9RZ9SPxAUlkyTeplzSngE
r2wAn2uxLbX7TYcMEmLBi/y28rEDgKk5
=QjbV
-END PGP SIGNATURE-
--- mod_status.c.orig 2010-06-10 16:06:48.550253580 +0200
+++ mod_status.c 2010-06-10 16:05:59.910253580 +0200
@@ -99,6 +99,20 @@
module AP_MODULE_DECLARE_DATA status_module;
+
+
+/* custom name for ServerStatus-Handlername. Prevents
+ * htaccess users from simply Setting
+ *
+ * 'SetHandler server-status'
+ *
+ * in their htaccess-file to gain infos.
+*/
+
+typedef struct {
+ char *Handlername;
+} modstatus_config;
+
static int server_limit, thread_limit;
/* Implement 'ap_run_status_hook'. */
@@ -115,6 +129,31 @@
static pid_t child_pid;
#endif
+
+/* set the handlername defined in
+ * serverconfig
+ */
+static const char *set_serverstatus_handler_name(cmd_parms *cmd, void *dummy, const char *arg)
+{
+ modstatus_config *s_cfg = ap_get_module_config(cmd->server->module_config, &status_module);
+ s_cfg->Handlername = (char *) arg;
+ return NULL;
+}
+
+/*
+ * creates the configuration records.
+ */
+static void *create_modstatus_config(apr_pool_t *p, server_rec *s)
+{
+modstatus_config *newcfg;
+// allocate space for the configuration structure from the provided pool p.
+newcfg = (modstatus_config *) apr_pcalloc(p, sizeof(modstatus_config));
+// set the default value for the status-handler-string.
+newcfg->Handlername = "server-status";
+// return the new server configuration structure.
+return (void *) newcfg;
+}
+
/*
* command-related code. This is here to prevent use of ExtendedStatus
* without status_module included.
@@ -142,6 +181,8 @@
static const command_rec status_module_cmds[] =
{
+AP_INIT_TAKE1("ServerStatusHandlerName", set_serverstatus_handler_name, NULL, RSRC_CONF,
+ "\"String\" to define the Handler for Serverstatus-Handlername. Used to be \"server-status\""),
AP_INIT_FLAG("ExtendedStatus", set_extended_status, NULL, RSRC_CONF,
"\"On\" to enable extended status information, \"Off\" to disable"),
AP_INIT_FLAG("SeeRequestTail", set_reqtail, NULL, RSRC_CONF,
@@ -248,8 +289,11 @@
clock_t tu, ts, tcu, tcs;
ap_generation_t worker_generation;
+modstatus_config *s_cfg = ap_get_module_config(r->server->module_config, &status_module);
+
if (strcmp(r->handler, STATUS_MAGIC_TYPE) &&
-strcmp(r->handler, "server-status")) {
+//strcmp(r->handler, "server-status-vs")) {
+strcmp(r->handler, s_cfg->Handlername)) {
return DECLINED;
}
@@ -873,7 +917,7 @@
STANDARD20_MODULE_STUFF,
NULL, /* dir config creater */
NULL, /* dir merger --- default is to override */
-NULL, /* server config */
+create_modstatus_config,/* server config */
NULL, /* merge server config */
status_module_cmds, /* command table */
register_hooks /* register_hooks */
RE: server-status and privacy
> -Original Message- > From: Jeff Trawick > Sent: Mittwoch, 23. Juni 2010 18:43 > To: dev@httpd.apache.org > Subject: Re: server-status and privacy > > On Wed, Jun 23, 2010 at 12:09 PM, William A. Rowe Jr. > wrote: > > On 6/23/2010 10:49 AM, Jim Jagielski wrote: > >> > >> On Jun 21, 2010, at 1:07 PM, Jeff Trawick wrote: > >> > >>> On Mon, Jun 21, 2010 at 8:40 AM, Jim Jagielski > wrote: > >>>> There have been a few reports regarding how server-status "leaks" > >>>> info, mostly about our (the ASF's) open use of server-status and > >>>> how IP addresses are exposed. > >>>> > >>>> I'm thinking about a patch that adjusts server-status/mod_status > >>>> to have a "public vs. private" setting... Public would be to > >>>> have IP addresses exposed as public info; private would be to > >>>> not expose 'em (keep 'em private). > >>> > >>> use mod_sed or similar on apache.org to change the client > IP address > >>> field to "?" > >> > >> True... so I'm guessing this means that the patch would > >> be unacceptable? > > > > If it's an obfuscation (truncated hash of IP?) that lets > the admin/users > > see that one individual has tying up 10 connections, I > don't think it's > > a bad idea to patch (mod_sed isn't going to do that > effectively). +/-0 > > on patching to disable the field entirely. > > > > admins can set up unobfuscated /server-status-foo with auth required; > if they care about a single client IP tying up n connections, they > want to see IP address too > > nearly zero sites want a public server-status page with > obfuscated/omitted client IP address; why write new code to handle > that? > +1 on that. I see no need for a patch here. The situation on the apache.org site is IMHO unique and should be fixed with mod_sed / mod_substitute. Regards Rüdiger
Re: server-status and privacy
On 21 Jun 2010, at 13:40, Jim Jagielski wrote: > I'm thinking about a patch that adjusts server-status/mod_status > to have a "public vs. private" setting... Public would be to > have IP addresses exposed as public info; private would be to > not expose 'em (keep 'em private). > > Comments? +1 on the principle. How about tying it to password-protection? If r->user is NULL, then blank out IP addresses? -- Nick Kew
Re: server-status and privacy
On 22 Jun 2010, at 08:20, g...@schwicking.de wrote: > Just as a hint: i posted a patch about two weeks ago, Pointer? Was that somewhere in bugzilla? I don't see it on-list. -- Nick Kew
Re: server-status and privacy
On Wed, Jun 23, 2010 at 12:09 PM, William A. Rowe Jr. wrote: > On 6/23/2010 10:49 AM, Jim Jagielski wrote: >> >> On Jun 21, 2010, at 1:07 PM, Jeff Trawick wrote: >> >>> On Mon, Jun 21, 2010 at 8:40 AM, Jim Jagielski wrote: >>>> There have been a few reports regarding how server-status "leaks" >>>> info, mostly about our (the ASF's) open use of server-status and >>>> how IP addresses are exposed. >>>> >>>> I'm thinking about a patch that adjusts server-status/mod_status >>>> to have a "public vs. private" setting... Public would be to >>>> have IP addresses exposed as public info; private would be to >>>> not expose 'em (keep 'em private). >>> >>> use mod_sed or similar on apache.org to change the client IP address >>> field to "?" >> >> True... so I'm guessing this means that the patch would >> be unacceptable? > > If it's an obfuscation (truncated hash of IP?) that lets the admin/users > see that one individual has tying up 10 connections, I don't think it's > a bad idea to patch (mod_sed isn't going to do that effectively). +/-0 > on patching to disable the field entirely. > admins can set up unobfuscated /server-status-foo with auth required; if they care about a single client IP tying up n connections, they want to see IP address too nearly zero sites want a public server-status page with obfuscated/omitted client IP address; why write new code to handle that?
Re: server-status and privacy
On 6/23/2010 10:49 AM, Jim Jagielski wrote: > > On Jun 21, 2010, at 1:07 PM, Jeff Trawick wrote: > >> On Mon, Jun 21, 2010 at 8:40 AM, Jim Jagielski wrote: >>> There have been a few reports regarding how server-status "leaks" >>> info, mostly about our (the ASF's) open use of server-status and >>> how IP addresses are exposed. >>> >>> I'm thinking about a patch that adjusts server-status/mod_status >>> to have a "public vs. private" setting... Public would be to >>> have IP addresses exposed as public info; private would be to >>> not expose 'em (keep 'em private). >> >> use mod_sed or similar on apache.org to change the client IP address >> field to "?" > > True... so I'm guessing this means that the patch would > be unacceptable? If it's an obfuscation (truncated hash of IP?) that lets the admin/users see that one individual has tying up 10 connections, I don't think it's a bad idea to patch (mod_sed isn't going to do that effectively). +/-0 on patching to disable the field entirely.
Re: server-status and privacy
On Jun 21, 2010, at 1:07 PM, Jeff Trawick wrote: > On Mon, Jun 21, 2010 at 8:40 AM, Jim Jagielski wrote: >> There have been a few reports regarding how server-status "leaks" >> info, mostly about our (the ASF's) open use of server-status and >> how IP addresses are exposed. >> >> I'm thinking about a patch that adjusts server-status/mod_status >> to have a "public vs. private" setting... Public would be to >> have IP addresses exposed as public info; private would be to >> not expose 'em (keep 'em private). > > use mod_sed or similar on apache.org to change the client IP address > field to "?" > True... so I'm guessing this means that the patch would be unacceptable?
Re: server-status and privacy
On 23/06/2010 8:20 p.m., Paul Querna wrote: 4) How is it a "completely unreasonable violation" of privacy to show request urls to a public website, with zero private content or anything even remotely sensitive, and associate that with an IP address? IP address X was looking up how to configure Hadoop... and that harms someone how? We aren't a search engine, we don't host anything that is embarrassing or private on the public server-status pages. So if an attacker sees your company researching patches for a particular vulnerability reported on apache.org, that wouldn't be useful to them? I don't know what hellhole you live in where companies casually broadcasing your every interaction with them is considered acceptable. Nicholas Sherlock
Re: server-status and privacy
On Tue, Jun 22, 2010 at 6:23 PM, Nicholas Sherlock wrote: > On 22/06/2010 12:40 a.m., Jim Jagielski wrote: >> >> There have been a few reports regarding how server-status "leaks" >> info, mostly about our (the ASF's) open use of server-status and >> how IP addresses are exposed. >> >> I'm thinking about a patch that adjusts server-status/mod_status >> to have a "public vs. private" setting... Public would be to >> have IP addresses exposed as public info; private would be to >> not expose 'em (keep 'em private). >> >> Comments? > > I can't believe when I informed apache.org of this issue 70 days ago, that > the immediate response wasn't simply to disable server-status or restrict it > to clients from within Apache's network. It is a completely unreasonable > violation of your customer's privacy to broadcast their IP addresses and > viewing habits. 1) This configuration has been present on apache.org for at least 10 years, probably longer. Maybe the rest of the internet's expectation of IP address privacy has changed in that time, but the server-status on apache.org has been there for a long time. 2) There is no 'apache network' to restrict access from -- the real asf server admins are random people all over the world. 3) I'm not really sure this belongs on d...@httpd at all, infrastruct...@apache.org is likely where you want to send complaints of this type. A feature request to add obfuscation to mod_status might be interesting to some, but its not really related to apache.org's configuration. 4) How is it a "completely unreasonable violation" of privacy to show request urls to a public website, with zero private content or anything even remotely sensitive, and associate that with an IP address? IP address X was looking up how to configure Hadoop... and that harms someone how? We aren't a search engine, we don't host anything that is embarrassing or private on the public server-status pages. Thanks, Paul
Re: server-status and privacy
On 22/06/2010 12:40 a.m., Jim Jagielski wrote: There have been a few reports regarding how server-status "leaks" info, mostly about our (the ASF's) open use of server-status and how IP addresses are exposed. I'm thinking about a patch that adjusts server-status/mod_status to have a "public vs. private" setting... Public would be to have IP addresses exposed as public info; private would be to not expose 'em (keep 'em private). Comments? I can't believe when I informed apache.org of this issue 70 days ago, that the immediate response wasn't simply to disable server-status or restrict it to clients from within Apache's network. It is a completely unreasonable violation of your customer's privacy to broadcast their IP addresses and viewing habits. I sat and sniffed server-status today for an hour and saw lots of interesting things. These people thought it was interesting too: Client - Requests for "/server-status?auto" '121.2.73.140', '2' '204.232.198.45', '18' '209.40.196.203', '261' '217.193.165.235', '27' '222.73.44.146', '10' '222.73.45.200', '15' '222.73.68.35', '7' '222.73.86.253', '17' '61.57.131.230', '100' '62.49.67.115', '18' '64.27.116.177', '3' '67.188.126.141', '3' '67.199.134.1', '62' '68.87.42.115', '13' '69.70.70.186', '12' '74.103.140.133', '172' '81.0.134.157', '1' '92.106.225.35', '42' Client - Requests for "/server-status" '118.90.8.44', '550' <- That's me '119.63.88.205', '80' '187.34.7.120', '1' '217.193.165.235', '16' '222.73.68.35', '1' '60.195.252.106', '24' '64.27.116.177', '12' '68.87.42.115', '68' '81.0.134.157', '37' '92.106.225.35', '1' Cheers, Nicholas Sherlock
Re: server-status and privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, > I'm thinking about a patch that adjusts server-status/mod_status > to have a "public vs. private" setting... Public would be to > have IP addresses exposed as public info; private would be to > not expose 'em (keep 'em private). > > Comments? Just as a hint: i posted a patch about two weeks ago, that enables a (sort of) privacy setting for the server-status. The patch adds a new directive (ServerStatusHandlerName ) and enables the admin to customize the handlername for the mod_status module. That way, other users (in a shared hosting enviroment), can not simply use "SetHandler server-status" in their htaccess-files anymore. For us that does the trick. - From my experience, no admin (knowingly) makes the server-status available to the public (and of course shouldnt). It should be used by admins to view the servers current load, child status, remote ips and for example to investigate in heavy-load situations (etc.). What point does a server-status have, if i cant see the remote ip (and for example roughly sum them up), use the requested url shown to reproduce some sort of error or see the status of the current apache childs and realize, that too many are in WAIT? - From my point of view, renaming/customizing the handler is sufficient and my patch already does that :-). regards volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwgZCQACgkQHaTGAGocg2KtFQCfaWzucPVij8bgZmdvx8uSYJJu TKAAn3kQmxcgOXBo5tJk2yrhOV9rmNbj =mjjR -END PGP SIGNATURE-
Re: server-status and privacy
On Mon, Jun 21, 2010 at 8:40 AM, Jim Jagielski wrote: > There have been a few reports regarding how server-status "leaks" > info, mostly about our (the ASF's) open use of server-status and > how IP addresses are exposed. > > I'm thinking about a patch that adjusts server-status/mod_status > to have a "public vs. private" setting... Public would be to > have IP addresses exposed as public info; private would be to > not expose 'em (keep 'em private). use mod_sed or similar on apache.org to change the client IP address field to "?"
Re: server-status and privacy
On 6/21/2010 7:40 AM, Jim Jagielski wrote: > There have been a few reports regarding how server-status "leaks" > info, mostly about our (the ASF's) open use of server-status and > how IP addresses are exposed. > > I'm thinking about a patch that adjusts server-status/mod_status > to have a "public vs. private" setting... Public would be to > have IP addresses exposed as public info; private would be to > not expose 'em (keep 'em private). > > Comments? Sounds sensible, but it becomes a problem to distinguish clients. What about 8 or 9 digits of a sha1 hash on the client (e.g. something that would look a bit like a mac), purely invented and truncated to allow the admin to see patterns in who is accessing the machine?
Re: server-status and privacy
On 21.06.2010 14:40, Jim Jagielski wrote: There have been a few reports regarding how server-status "leaks" info, mostly about our (the ASF's) open use of server-status and how IP addresses are exposed. I'm thinking about a patch that adjusts server-status/mod_status to have a "public vs. private" setting... Public would be to have IP addresses exposed as public info; private would be to not expose 'em (keep 'em private). Comments? Seems necessary according to privacy laws in various countries. What about the request URL and the VHost name? Both are not necessarily publicly known information, i.e. you could "leak" what URLs respectively VHosts are there. More of a security than a privacy issue though. Finally an attacker can derive the MPM sizing and check the effectiveness of DOS attacks from the server status, but I guess admins afraid about that will never (publicly) enable the server status. So IMHO: w.r.t. privacy, removing the client IP is good and might even be necessary for admins who only want to provide the server status to a restricted group of users. Optionally removing VHost and URL might allow more admins to make the server status available to an even bigger group of people, but if there are only two choices, full data and restricted data, I would prefer them to be still shown even in the restricted mode. Regards, Rainer
server-status and privacy
There have been a few reports regarding how server-status "leaks" info, mostly about our (the ASF's) open use of server-status and how IP addresses are exposed. I'm thinking about a patch that adjusts server-status/mod_status to have a "public vs. private" setting... Public would be to have IP addresses exposed as public info; private would be to not expose 'em (keep 'em private). Comments?
Re: server-status-handler information leak
On 2010-06-11 at 08:39, Volker wrote: > Hi, > > while playing around with handlers, i noticed, that any user can > register the 'server-status'-handler by putting > > > SetHandler server-status > > > in an htacces-File. This can not be prevented by using a alternating > AllowOverride-directives, since 'SetHandler' is part of 'FileInfo' which > also holds ErrorDocuments, mod_rewrite, etc. > > Since the server-status-handler offers information one might not want > others to have access to (for example a massive shared hosting > environment), i created a small patch that enables a custom handlername > for the server-status-module. Just thought someone else might have use > for it. > > What this patch does: > - reserves memory for directive with parameter (AP_INIT_TAKE1) > - adds a function for creating config-records (create_modstatus_config) > - adds a function to set the handlername (set_serverstatus_handler_name) > > If the handlername is not set using the directive, it defaults to the > old 'server-status' and continues to work with the old setting. ... > Any comments, suggestions, improvements and/or critical comments are > welcome. Thanks for the problem report and patch. Since it doesn't seem that anyone has responded yet (unless I missed it), I suggest that you open a bug report and attach your patch there so it's not forgotten. I keep thinking there ought to be a better solution for this, but I can't think of one so far. Dan
Re: server-status-handler information leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> attached files:
> mod_status.c - the complete module
> mod_status-diff.patch - the patch with all changes made
and of course, the files... :-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwSLtoACgkQHaTGAGocg2LgLgCgo3NBP4+RSFgAaC+gOKGUyrcY
xzEAnRLL3bcOVRl0F9lMuEyNYQHIsXug
=zYvg
-END PGP SIGNATURE-
/* 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.
*/
/* Status Module. Display lots of internal data about how Apache is
* performing and the state of all children processes.
*
* To enable this, add the following lines into any config file:
*
*
* SetHandler server-status
*
*
* You may want to protect this location by password or domain so no one
* else can look at it. Then you can access the statistics with a URL like:
*
* http://your_server_name/server-status
*
* /server-status - Returns page using tables
* /server-status?notable - Returns page for browsers without table support
* /server-status?refresh - Returns page with 1 second refresh
* /server-status?refresh=6 - Returns page with refresh every 6 seconds
* /server-status?auto - Returns page with data for automatic parsing
*
* Mark Cox, m...@ukweb.com, November 1995
*
* 12.11.95 Initial version for www.telescope.org
* 13.3.96 Updated to remove rprintf's [Mark]
* 18.3.96 Added CPU usage, process information, and tidied [Ben Laurie]
* 18.3.96 Make extra Scoreboard variables #definable
* 25.3.96 Make short report have full precision [Ben Laurie suggested]
* 25.3.96 Show uptime better [Mark/Ben Laurie]
* 29.3.96 Better HTML and explanation [Mark/Rob Hartill suggested]
* 09.4.96 Added message for non-STATUS compiled version
* 18.4.96 Added per child and per slot counters [Jim Jagielski]
* 01.5.96 Table format, cleanup, even more spiffy data [Chuck Murcko/Jim J.]
* 18.5.96 Adapted to use new rprintf() routine, incidentally fixing a missing
* piece in short reports [Ben Laurie]
* 21.5.96 Additional Status codes (DNS and LOGGING only enabled if
* extended STATUS is enabled) [George Burgyan/Jim J.]
* 10.8.98 Allow for extended status info at runtime (no more STATUS)
* [Jim J.]
*/
#define CORE_PRIVATE
#include "httpd.h"
#include "http_config.h"
#include "http_core.h"
#include "http_protocol.h"
#include "http_main.h"
#include "ap_mpm.h"
#include "util_script.h"
#include
#include "scoreboard.h"
#include "http_log.h"
#include "mod_status.h"
#if APR_HAVE_UNISTD_H
#include
#endif
#define APR_WANT_STRFUNC
#include "apr_want.h"
#include "apr_strings.h"
#ifdef NEXT
#if (NX_CURRENT_COMPILER_RELEASE == 410)
#ifdef m68k
#define HZ 64
#else
#define HZ 100
#endif
#else
#include
#endif
#endif /* NEXT */
#define STATUS_MAXLINE 64
#define KBYTE 1024
#define MBYTE 1048576L
#define GBYTE 1073741824L
#ifndef DEFAULT_TIME_FORMAT
#define DEFAULT_TIME_FORMAT "%A, %d-%b-%Y %H:%M:%S %Z"
#endif
#define STATUS_MAGIC_TYPE "application/x-httpd-status"
module AP_MODULE_DECLARE_DATA status_module;
/* custom name for ServerStatus-Handlername. Prevents
* htaccess users from simply Setting
*
* 'SetHandler server-status'
*
* in their htaccess-file to gain infos.
*/
typedef struct {
char *Handlername;
} modstatus_config;
static int server_limit, thread_limit;
/* Implement 'ap_run_status_hook'. */
APR_IMPLEMENT_OPTIONAL_HOOK_RUN_ALL(ap, STATUS, int, status_hook,
(request_rec *r, int flags),
(r, flags),
OK, DECLINED)
#ifdef HAVE_TIMES
/* ugh... need to know if we're running with a pthread implementation
* such as linuxthreads that treats individual threads as distinct
* processes; that affects how we add up CPU time in a process
*/
static pid_t child_pid;
#endif
/* set the handlername defined in
* serverconfig
*/
static const char *set_serverstatus_handler_name(cmd_parms *cmd, void *dummy, const ch
server-status-handler information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, while playing around with handlers, i noticed, that any user can register the 'server-status'-handler by putting SetHandler server-status in an htacces-File. This can not be prevented by using a alternating AllowOverride-directives, since 'SetHandler' is part of 'FileInfo' which also holds ErrorDocuments, mod_rewrite, etc. Since the server-status-handler offers information one might not want others to have access to (for example a massive shared hosting environment), i created a small patch that enables a custom handlername for the server-status-module. Just thought someone else might have use for it. What this patch does: - - reserves memory for directive with parameter (AP_INIT_TAKE1) - - adds a function for creating config-records (create_modstatus_config) - - adds a function to set the handlername (set_serverstatus_handler_name) If the handlername is not set using the directive, it defaults to the old 'server-status' and continues to work with the old setting. How to test: 1. build and install the module with apxs2 2. create a new directive like the following in the root-configuration of the server ServerStatusHandlerName statusteststring 3. set a handler somewhere like the following: SetHandler statusteststring attached files: mod_status.c - the complete module mod_status-diff.patch - the patch with all changes made Any comments, suggestions, improvements and/or critical comments are welcome. best regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwSLmIACgkQHaTGAGocg2KOXACfYmRIj08gOU5F6If2EFAw oSMAnRO914zl5gqnggpqcXgOmdyVA37j =diTB -END PGP SIGNATURE-
[mod_fcgid PATCH] display elapsed instead of absolute time in server status
to represent when process was started and when it was last used.
Any concerns with this somewhat gratuitous change?
(also changes "Requests handled" to "Accesses")
now:
Pid Active IdleAccessesState
30890 99 0 1479Ready
and after all such tables:
"Active and Idle are time active and time since last request, in seconds."
before:
Pid Start time Last active timeRequest handled State
18135 1258059310 1258059318 126 Ready
17670 1258059285 1258059327 732 Ready
17671 1258059286 1258059327 948 Ready
18136 1258059310 1258059327 294 Ready
17672 1258059287 1258059320 331 Ready
Index: modules/fcgid/mod_fcgid.c
===
--- modules/fcgid/mod_fcgid.c (revision 901434)
+++ modules/fcgid/mod_fcgid.c (working copy)
@@ -295,6 +295,7 @@
gid_t last_gid = 0;
uid_t last_uid = 0;
apr_size_t last_share_grp_id = 0;
+apr_time_t now;
const char *last_virtualhost = NULL;
const char *basename, *tmpbasename;
fcgid_procnode *proc_table = proctable_get_table_array();
@@ -353,6 +354,8 @@
}
proctable_unlock(r);
+now = apr_time_now();
+
/* Sort the array */
if (num_ent != 0)
qsort((void *)ar, num_ent, sizeof(fcgid_procnode *),
@@ -383,8 +386,8 @@
/* Create a new table for this process info */
ap_rputs("\n\n"
- "PidStart timeLast active time"
- "Requests handledState"
+ "PidActiveIdle"
+ "AccessesState"
"\n", r);
last_inode = current_node->inode;
@@ -396,13 +399,18 @@
}
ap_rprintf(r, "%" APR_PID_T_FMT "%" APR_TIME_T_FMT
"%" APR_TIME_T_FMT "%d%s",
- current_node->proc_id.pid,
apr_time_sec(current_node->start_time),
- apr_time_sec(current_node->last_active_time),
+ current_node->proc_id.pid,
+ apr_time_sec(now - current_node->start_time),
+ apr_time_sec(now - current_node->last_active_time),
current_node->requests_handled,
get_state_desc(current_node));
}
-if (num_ent != 0)
+if (num_ent != 0) {
ap_rputs("\n\n", r);
+ap_rputs("\n"
+ "Active and Idle are time active and time
since\n"
+ "last request, in seconds.\n", r);
+}
return OK;
}
Re: balancer-manager and server-status feature request.
On Nov 16, 2009, at 5:52 AM, Mladen Turk wrote: > Regarding xml data, it is my long standing wish to create > log output filter sub module system where the log lines would > go trough a VFS filter capable of writing to xml, database, etc > (depending on the VFS implementation). > *grin* I'd been mulling over the same idea... a data-set filter that can take data and output it as XML, HTML, etc...
Re: balancer-manager and server-status feature request.
On 16/11/09 11:33, Mark Watts wrote: The statistics one gets from both /balancer-manager and mod_status are useful but of course only exist until httpd is restarted. It would be nice if they could be configured to periodically write some lines to the error log (at LogLevel info or so) with these statistics so the data can be preserved. This could be done using watchdog module that would fire some balancer log module. Regarding xml data, it is my long standing wish to create log output filter sub module system where the log lines would go trough a VFS filter capable of writing to xml, database, etc (depending on the VFS implementation). If you came up with such a module I'd be happy to review it :) Regards -- ^TM
balancer-manager and server-status feature request.
The statistics one gets from both /balancer-manager and mod_status are useful but of course only exist until httpd is restarted. It would be nice if they could be configured to periodically write some lines to the error log (at LogLevel info or so) with these statistics so the data can be preserved. This would make it easy to parse by log monitoring tools and also allow for analysis if desired. XML output of both would be the icing on the cake :) Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer, Managed Services Manpower www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part
[PATCH 30730] mod_actions and Server-Status (Patch review request).
Hi, I am Basant and I work for Sun Microsystems Inc. in web tier group. I have submitted the patch for 30730. Bug Id : 30730 http://issues.apache.org/bugzilla/show_bug.cgi?id=30730 Summary : mod_actions and Server-Status Patch uri : http://issues.apache.org/bugzilla/attachment.cgi?id=19706 I would like to make a humble review request for the patch. Thanks and Regards, Basant.
Re: server-status traffic bug
On Dec 28, 2003, at 6:55 PM, xmb wrote: Morning, i just saw something weird while the server had heavy load for a day Server uptime: 28 days 3 hours 33 minutes 54 seconds Total accesses: 5327861 - Total Traffic: 102.0 GB Server uptime: 28 days 3 hours 45 minutes 44 seconds Total accesses: 5331468 - Total Traffic: 99.0 GB the accumulated totals only include processes currently owning a scoreboard slot; the totals won't be accurate unless you disable exiting of child processes so in that 12 minute period, at least one child process exited (presumably due to MaxRequestsPerChild or MaxSpareThreads/MaxSpareServers), and its counts were lost
server-status traffic bug
Morning, i just saw something weird while the server had heavy load for a day Server uptime: 28 days 3 hours 33 minutes 54 seconds Total accesses: 5327861 - Total Traffic: 102.0 GB Server uptime: 28 days 3 hours 45 minutes 44 seconds Total accesses: 5331468 - Total Traffic: 99.0 GB and after 9 hours: Server uptime: 28 days 12 hours 33 minutes 4 seconds Total accesses: 5449896 - Total Traffic: 86.6 GB (and oh well, a few mins later) Server uptime: 28 days 12 hours 48 minutes 47 seconds Total accesses: 5453416 - Total Traffic: 87.1 GB the actual traffic usage up to the second paste here was around 48GB gotten from the apache logs with mod_logio (and iptables logging) the whole thing on a debian sid box, release apache 2.0.48, compiled with gcc ~3.3.2 around two months ago, only addition was -march=i686
RES: server-status
Hi all! I´m having a little problem with server-status that it´s returning me forbidden every time i try it. Below you can see my configuration in httpd.conf, and the error returned in the logs. SetHandler server-status Order deny,allow Deny from all Allow from localhost [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by server configuration: /home/vhosts/l As you can see i´m using mod_vhosts compiled into apache, and also mod_info and mod_status. I´ve Tried changing "localhost" to "127.0.0.1", tried to invert the Order to allow,deny and coment the Deny line, but nothing worked. The strange thing is when i open the permition to Allow all and coment the deny line, it works fine, but for security reasons it can´t happens. Anyone can help me? Thaks in advanced.
RES: server-status
Thanks for the tip, but i´ve already tried it, and didn´t work. If you have any others ideas i apreciate. Att, Daniel Martins Abad Analista de Suporte Tel: 3365-0186 [EMAIL PROTECTED] #ICQ-64604947 Você tem o Webmail gratuito do Cidade Internet? http://webmail.cidadeinternet.com.br -Mensagem original- De: Jerry Baker [mailto:[EMAIL PROTECTED]] Enviada em: terça-feira, 26 de março de 2002 17:04 Para: [EMAIL PROTECTED] Assunto: Re: server-status Daniel Abad wrote: > > Hi all! > > I´m having a little problem with server-status that it´s returning me > forbidden every time i try it. Below you can see my configuration in > httpd.conf, and the error returned in the logs. > > > SetHandler server-status > Order deny,allow > Deny from all > Allow from localhost > > > [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by > server configuration: /home/vhosts/l > > As you can see i´m using mod_vhosts compiled into apache, and also mod_info > and mod_status. The strange thing is when i open the permition to Allow all > and coment the deny line, it works fine, but for security reasons it can´t > happens. > > Anyone can help me? > > Thaks in advanced. > > Dan. Try changing "localhost" to "127.0.0.1". I imagine that Apache never sees that your machine is called "localhost" since it is probably not set up to resolve IP addresses accessing it. -- Jerry Baker
Re: server-status
Daniel Abad wrote: > > Hi all! > > I´m having a little problem with server-status that it´s returning me > forbidden every time i try it. Below you can see my configuration in > httpd.conf, and the error returned in the logs. > > > SetHandler server-status > Order deny,allow > Deny from all > Allow from localhost > > > [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by > server configuration: /home/vhosts/l > > As you can see i´m using mod_vhosts compiled into apache, and also mod_info > and mod_status. The strange thing is when i open the permition to Allow all > and coment the deny line, it works fine, but for security reasons it can´t > happens. > > Anyone can help me? > > Thaks in advanced. > > Dan. Try changing "localhost" to "127.0.0.1". I imagine that Apache never sees that your machine is called "localhost" since it is probably not set up to resolve IP addresses accessing it. -- Jerry Baker
server-status
Hi all! I´m having a little problem with server-status that it´s returning me forbidden every time i try it. Below you can see my configuration in httpd.conf, and the error returned in the logs. SetHandler server-status Order deny,allow Deny from all Allow from localhost [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by server configuration: /home/vhosts/l As you can see i´m using mod_vhosts compiled into apache, and also mod_info and mod_status. The strange thing is when i open the permition to Allow all and coment the deny line, it works fine, but for security reasons it can´t happens. Anyone can help me? Thaks in advanced. Dan.
Re: server-status
If the mod's syntax works anyting like Cisco ACL features than you will want
to put this instead
SetHandler server-status
Order allow,deny
Allow from localhost
Deny from all
Just a guess
##
Darrel Clute, CCNA
Partner/CEO
Acumen Technology Group
Clute Technologies
#
- Original Message -
From: "Daniel Abad" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 17, 2002 5:14 PM
Subject: server-status
Hi all!
I´m having a little problem with server-satatus that it´s returning me
forbidden every time i try it. Below you can see my configuration in
httpd.conf, and the error returned in the logs.
SetHandler server-status
Order deny,allow
Deny from all
Allow from localhost
[Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by
server configuration: /home/vhosts/l
As you can see i´m using mod_vhosts compiled into apache, and also mod_info
and mod_status. The strange thing is when i open the permition to Allow all
and coment the deny line, it works fine, but for security reasons it can´t
happens.
Anyone can help me?
Thaks in advanced.
Dan.
server-status
Hi all! I´m having a little problem with server-satatus that it´s returning me forbidden every time i try it. Below you can see my configuration in httpd.conf, and the error returned in the logs. SetHandler server-status Order deny,allow Deny from all Allow from localhost [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by server configuration: /home/vhosts/l As you can see i´m using mod_vhosts compiled into apache, and also mod_info and mod_status. The strange thing is when i open the permition to Allow all and coment the deny line, it works fine, but for security reasons it can´t happens. Anyone can help me? Thaks in advanced. Dan.
Re: www.apache.org/server-status
Bill Stoddard wrote:
>
> This looks seriously hosed... There are clearly more than 89 requests being handled
>
> Current Time: Monday, 22-Oct-2001 10:26:59 PDT
> Restart Time: Monday, 22-Oct-2001 08:20:27 PDT
> Parent Server Generation: 2
> Server uptime: 2 hours 6 minutes 32 seconds
> Total accesses: 411687 - Total Traffic: 16.9 GB
> CPU Usage: u361.164 s597.625 cu626.703 cs184.898 - 23.3% CPU load
> 54.2 requests/sec - 2.3 MB/second - 43.1 kB/request
> 89 requests currently being processed, 11 idle workers
> W_W.KKWWCW_WWW_WC_WWW_WWWCWWW.WKCKWWW.KW
> KKKW_KWW_WKWKWW_WKWWW_KWWKW_WWCWW_WCWKWK
> WWKWWKWWWK_WWW.WWW_WWWKWWW_WWKKWKWGWWWK__WWW_KWK
> _WW_KWWCWKWW_WKWC_W_WWWKWKRKW_KCWWWKWW_WGW_W
> KWWKWWWCWWRKW_WWKW_WGWK_W_WKW_WWW___
> WK_WWW_WWKWWWKWW_WWK_GWWKW._WK_WWR_WW_WWKKWWKCWW
> KW_WWW_K_WWWKWWKW_W_WKKK__K_WWCWWCWWKCWKWWWKWKWKWW__
> K.W.WW...W._
> W...
For sure. It took me a long time to figure out that we were hitting
MaxClients earlier, because that number was so low.
To save people from counting, there are 64 state characters per line in
the status display above. I come up with 443 processes that aren't idle
('_') or dead ('.').
Perhaps we ought to provide a grand total of live workers, so an admin
can easily tell if there's a MaxClients problem, or whatever we end up
calling it. Then we could display subtotals by state along with the
"Scoreboard Key". We could save some room by not displaying unused
states. I've never seen some of those states.
There are some other bogusities in the status displays: child generation
number is 1 more often than it should be, negative numbers in the "SS"
column, "Req" column is always 0, and the "Conn" column looks dubious.
Greg
www.apache.org/server-status
This looks seriously hosed... There are clearly more than 89 requests being handled Current Time: Monday, 22-Oct-2001 10:26:59 PDT Restart Time: Monday, 22-Oct-2001 08:20:27 PDT Parent Server Generation: 2 Server uptime: 2 hours 6 minutes 32 seconds Total accesses: 411687 - Total Traffic: 16.9 GB CPU Usage: u361.164 s597.625 cu626.703 cs184.898 - 23.3% CPU load 54.2 requests/sec - 2.3 MB/second - 43.1 kB/request 89 requests currently being processed, 11 idle workers W_W.KKWWCW_WWW_WC_WWW_WWWCWWW.WKCKWWW.KW KKKW_KWW_WKWKWW_WKWWW_KWWKW_WWCWW_WCWKWK WWKWWKWWWK_WWW.WWW_WWWKWWW_WWKKWKWGWWWK__WWW_KWK _WW_KWWCWKWW_WKWC_W_WWWKWKRKW_KCWWWKWW_WGW_W KWWKWWWCWWRKW_WWKW_WGWK_W_WKW_WWW___ WK_WWW_WWKWWWKWW_WWK_GWWKW._WK_WWR_WW_WWKKWWKCWW KW_WWW_K_WWWKWWKW_W_WKKK__K_WWCWWCWWKCWKWWWKWKWKWW__ K.W.WW...W._ W...
