You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2017/10/25 03:55:25 UTC
[Bug 61662] New: apachectl does not follow ports.conf
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
Bug ID: 61662
Summary: apachectl does not follow ports.conf
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P2
Component: Core
Assignee: bugs@httpd.apache.org
Reporter: kai@gss.us
Target Milestone: ---
/usr/sbin/apachectl is hardcoded to check port 80, instead of reading the port
from /etc/apache2/ports.conf which means that e.g. `apachectl status` fails for
servers which listen on non-standard ports.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #2 from Kai <ka...@gss.us> ---
Luca,
I sincerely hope you're not suggesting I resolve a runtime configuration
conflict by recompiling the software.
More generally, in stead of ports.conf, apachectl needs to obey the server's
Listen directive, or have its own configuration file which can be updated in
tandem with the server config.
Having to modify a /usr/sbin/ script in order to make the tool work, which is
not persistent across upgrades, is utterly unacceptable design.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #4 from Luca Toscano <to...@gmail.com> ---
(In reply to Kai from comment #2)
> Luca,
>
> I sincerely hope you're not suggesting I resolve a runtime configuration
> conflict by recompiling the software.
I was only trying to explain why apachectl behaves in the way that you
described, that's all :)
> More generally, in stead of ports.conf, apachectl needs to obey the server's
> Listen directive, or have its own configuration file which can be updated in
> tandem with the server config.
Using httpd's configuration might not be the best way to configure apachectl,
since you could, for example, have multiple Listens/ports combination but
mod-status configured only for one virtualhost.
> Having to modify a /usr/sbin/ script in order to make the tool work, which
> is not persistent across upgrades, is utterly unacceptable design.
I agree that apachectl status is not really configurable, but the functionality
should not be there in the first place in my opinion. Checking the health of
httpd can be done in several ways with other tools, that are build with some
logic that knows where/how to get mod-status' data.
Let me know if you have a use case that strictly requires apachectl status to
work, and we can discuss what to do.
Side note: I'd like to keep the conversation polite and constructive, since
httpd is maintained by a community of people that have no interest in turning
down ideas or improvements. So if you have a proposal or a patch that works for
your use case you are free to submit it for review :)
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #1 from Luca Toscano <to...@gmail.com> ---
Hi,
configure offers '--with-port' that afaics should be able to set a different
port for apachectl (see
https://github.com/apache/httpd/blob/trunk/support/apachectl.in#L59).
ports.conf is a known path for distributions that have adopted this convention,
but in my opinion it shouldn't be hardcoded anywhere.
Let me know if this solves your concern!
Thanks,
Luca
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #6 from Yann Ylavic <yl...@gmail.com> ---
(In reply to Kai from comment #5)
>
> Is there another command-line tool to query this information (aside from
> e.g. installing a browser) which is more suitable?
You could get all the "IP:port" some httpd instance is listening on with
something like:
# netstat -lntp |grep "`cat /path/to/httpd.pid`/httpd" |awk '{print $4}'
(it may depend on your exact netstat output, so adjust to your needs).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #7 from Eric Covener <co...@gmail.com> ---
(In reply to Kai from comment #5)
> Eric,
>
> Precisely how is it 'silly'?
> Is there another command-line tool to query this information (aside from
> e.g. installing a browser) which is more suitable?
the apachectl in the source distribution just runs lynx.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Severity|major |trivial
Resolution|--- |WONTFIX
--- Comment #3 from Eric Covener <co...@gmail.com> ---
"apachectl status" is silly to begin with, it unlikelt to be extended to find
an appropriate port to use by parsing the configuration.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 61662] apachectl does not follow ports.conf
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #5 from Kai <ka...@gss.us> ---
Eric,
Precisely how is it 'silly'?
Is there another command-line tool to query this information (aside from e.g.
installing a browser) which is more suitable?
Lucas,
I don't know if there is a _strict_ need for this tool, but, then again, it's
arguable we could do without most tools in most situations.
The issue is that, without it, I'm not aware of any way without a web browser
(or some facsimile thereof) to query that information; more particularly, the
only way to access the information (as documented by the module) is through the
web server on whatever host/port it's configured to listen on.
What the tool offers is (in theory) a reliable, consistent, standard way to get
this information. If it were designed properly, it would be useful for querying
the status of a server quickly, without having to determine the listening port
manually, install a web browser (even Links/Lynx aren't guaranteed to be
present on a headless machine, and nonstandard ports may very well be
firewalled, if apache is acting as a backend server for e.g. a nginx frontend),
and type out the address and port in order to get the info one needs.
I suppose curl makes a decent fallback for querying the status via ?auto, since
that doesn't fill the screen with HTML markup, but then I'm just typing out the
port manually every time instead of modifying the script every time I upgrade
apache.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org