On Sun, Jun 27, 2010 at 07:46:07AM +0200, Willy Tarreau wrote:
> 
> This idea goes in the right direction. However, right now all
> "stats" statements can be set in defaults section and automatically
> enable stats (which was a very bad idea from the beginning since it
> causes confusion between frontends and backends). So I think that
> adding this feature might be the opportunity to clean up that mess
> and refer to proper services, paving the way to other future services
> (cli, etc...). A good solution would be not to extend the current
> "stats" keyword and create a new "service" section which could be
> used approximately like this :
> 
>     service user-stats
>       handler stats
> 
>     service admin-stats
>       handler stats
>       stats auth XXX
>       stats level admin
>       ...
> 
>     frontend public
>       use-service user-stats if { url_beg /stats }
> 
>     frontend private
>       use-service admin-stats if { url_beg /stats } && { src 192.168.0.0/16 }
> 
> Later we could then migrate the current stats CLI to a similar service,
> create new services and bind them to TCP ports or Unix sockets, and use
> them as we want. This will be especially important later when we one day
> support SSL, because we'll be able to describe the service at the end of
> the stack.
> 
> Now if we go back to reality and consider what can easily be done right
> now without changing everything, then probably we'd just have the
> "stats level admin" statement, we should refuse it in defaults section,
> and we should emit a big warning in the logs if there's no auth, or even
> refuse to start, and only the redesign will allow that to work.
> 
The above or something like it sounds reasonable to implement, but I
don't currently have a need for it.  I'll try to get to it and if
someone else wants to do it, or help in the meantime that would be
great.  I completed my first attempt at a reasonable patch with no
authentication.  Since I am new to the code and may have done
something stupid I'd like to put it out there for review and/or
comment.

http://www.jpilot.org/testing/haproxy/Screenshot.png
http://www.jpilot.org/testing/haproxy/haproxy-post-maint-mode-1.4.8.patch

Judd

Reply via email to