Description of problem: Set up the haproxy router with default option, found the part of stats disappeared. when curl -u admin:$pass 127.0.0.1:1936 return 404 error Version-Release number of selected component (if applicable): openshift v3.6.131 kubernetes v1.6.1+5115d708d7 etcd 3.2.1 How reproducible: always Steps to Reproduce: 1. set up router oadm router 2. when the router is running and rsh router pod oc rsh $router_pod 3. curl -u admin:$password 127.0.0.1:1936 Actual results: step 3: 404 error Expected results: should can be accessed Additional info: $ cat haproxy.config | grep -i stats stats socket /var/lib/haproxy/run/haproxy.sock mode 600 level admin stats timeout 2m
This is a little tricky. The stats were changed in this release so that more information could be exposed. If you have an old router configuration and use it with the new router image it will expose the stats the same way. However, if you are using a new image with a new configuration generated by 'oadm router' it will not generate stats in the same way. You can delete the ROUTER_METRICS_TYPE environment variable from the dc to get the same behavior: oc env dc router ROUTER_METRICS_TYPE- Otherwise you can curl the new stats at: curl -u admin:$STATS_PASSWORD 127.0.0.1:1936/metrics There are debugging endpoints that are now exposed with the new style stats at: curl -u admin:$STATS_PASSWORD 127.0.0.1:1936/debug/pprof/
hi, Ben Bennett I knew we can access the metrics by 'curl -u admin:$STATS_PASSWORD 127.0.0.1:1936/metrics' but this cannot be accessed by web console. it will always return 'Forbidden'. since it do not have a way to input the user/pass. before version we can check the statistics of haproxy from web console by accessing 'ip:1936' and input the user/pass. if the function is changed. how can I do that? only using 'curl'? thanks.
BTW, I still can see this part code in haproxy-template.config {{- if and (and (ne .StatsUser "") (ne .StatsPassword "")) (gt .StatsPort 0) }} # Add your custom health check monitoring failure condition here. # monitor fail if <condition> stats enable stats hide-version stats realm Haproxy\ Statistics stats uri / stats auth {{.StatsUser}}:{{.StatsPassword}} {{- end }} {{- end }}
You can still get the old stats with: oc env dc router ROUTER_METRICS_TYPE- (i.e. unset ROUTER_METRICS_TYPE) You can pass the credentials on the URL with: http://admin:$STATS_PASSWORD@ip:1936/metrics But why the web browser is not prompting you for the password, I'm not sure. I'll look into it.
We are sending an http status code of 403 Forbidden: The request was valid, but the server is refusing action. The user might not have the necessary permissions for a resource, or may need an account of some sort. We should be sending a 401 Unauthorized: Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.[32] 401 semantically means "unauthenticated",[33] i.e. the user does not have the necessary credentials. This is not a release blocker.
PR https://github.com/openshift/origin/pull/15061
Commits pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/47270ca175d91822ae68ccab449c37dc287f475c Send HTTP Unauthorized (401) for router metrics URL We were previously sending Forbidden (403) which doesn't make the browser prompt for a username and password. It is better to send Unauthorized (401) so that they can present credentials using the browser widget rather than having to jam them in the URL. Fixes bug 1467257 (https://bugzilla.redhat.com/show_bug.cgi?id=1467257) https://github.com/openshift/origin/commit/a1d69a1f8ead02e43361b27d25a5c67f957e73a6 Merge pull request #15061 from knobunc/bug/bz1467257-send-http-unauthorized-for-metrics Automatic merge from submit-queue Send HTTP Unauthorized (401) for router metrics URL We were previously sending Forbidden (403) which doesn't make the browser prompt for a username and password. It is better to send Unauthorized (401) so that they can present credentials using the browser widget rather than having to jam them in the URL. Fixes bug 1467257 (https://bugzilla.redhat.com/show_bug.cgi?id=1467257)
Verified this bug on v3.7.0-0.127.0 will reply 401 instead of 403
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:3188