Re: Roadmap for 1.6
Hi Willy, I know that you are thinking of all sorts of wonderful things for HAProxy at the moment and reading through this email thread only empisises the amount of work that you and other cleaver people have put into making HAProxy in my opinion the only product that works. OK that sounds a little bit more sucky upy than it did in my head. Anyhow, as you have mentioned that its really the community that is helping drive the developement forward, how about some form of online vote system to help find out what the community would most like to have added to the next release and this could then be the main target of the next stable release. For example Open a vote for one month before all major development begins with say four items that are realisticly possible for adding into v1.6 after the month the one with the most becomes the main development focus for this release. I'm not saying that other things can't and shouldn't be added that would just be silly but this way us out here get what we think we really need and we continue to have a reliable and stable development process. Well thats it, light buld burnt out now. Thanks again to one and all for working on HAProxy. Yours, Scott
Re: Roadmap for 1.6
Hi Willy, Thank you for clearing this up for me. I now understand the direction that you are wanting to take more clearly now. I just wish that I could help more than by just using and reporting, I'm sure I'll get there though. ~Scott On 29/07/2014 09:33, Willy Tarreau wrote: Hi Scott, On Sun, Jul 27, 2014 at 03:40:10PM +0100, Scott McKeown | redIT wrote: Anyhow, as you have mentioned that its really the community that is helping drive the developement forward, how about some form of online vote system to help find out what the community would most like to have added to the next release and this could then be the main target of the next stable release. It already exists, it's the mailing list! Development is not based on a vote but on *real* efforts, and the best way to have a feature implemented is to contribute it. When you cannot contribute it, you at least need to explain your needs on the list so that they can be discussed and tailored to something implementable. In fact, this has worked for years so I firmly believe this will continue to work. Also, as I mentionned, I don't want a release to depend on an advertise feature set anymore, so that's one more reason for having things done in parallel and as contributions. For example Open a vote for one month before all major development begins with say four items that are realisticly possible for adding into v1.6 after the month the one with the most becomes the main development focus for this release. We really never know. Server-side keep-alive was realistic for 6-months after 1.4, and digging into it constantly proved more difficult with a very long trail of dependencies. So I don't want to bet anymore on ETAs for certain features. We have many examples like this, of things we have been forced to drop or at least delay so that we could perform deeper changes that were needed. I'm not saying that other things can't and shouldn't be added that would just be silly but this way us out here get what we think we really need and we continue to have a reliable and stable development process. There's another point I forgot to mention : despite a number of companies contributing to the project, most initiatives are done on a voluntary basis by enthousiasts on their spare time. Most of them have no idea how long it can take to implement something nor how much spare time they have to work on it. We *cannot* and *must not* wait for people's work to be completed before a release, and they must not feel bad for missing a deadline. That's the benefit of a merge window : if your code is not in good enough shape for version N, no rush, continue at your rhythm, you'll push it for N+1 a few months later. This process ensures that what people want actually is what will eventually get merged. Large companies can hire developers to get their features done quickly, and other users can take their time, nobody is waiting for them to finish. Best regards, Willy
Re: [PATCH/RFC 0/8] Email Alerts
Hi Willy, Can you please just confirm where this has been merged into as I've downloaded the v1.6-dev0 archive today and I can't see it in there also I've tried Horms github version at https://github.com/horms/haproxy/tree/devel/email-alert which does look to have all the options in but I can't test this on either the v1.5.11 branch or v1.6-dev0 Ta, Scott On 02/02/2015 23:40, Willy Tarreau wrote: So I've merged it now, all 8 patches. Now I trust you to provide the doc so that users can quickly start testing it. Do not hesitate either if you want to fix issues or change your mind about certain points you are not happy with, this is still in development, no worries! Thanks! Willy
Re: Haproxy 1.5 ssl redirect
Hi Sean,
I've got a setup that is somewhat like what you are after. I have
however, done it in a very dirrerent way for this very same reason.
Example below:
global
log /dev/log local4 debug
maxconn 4096
daemon
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers
ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH
ssl-default-bind-options no-sslv3
ssl-default-server-ciphers
ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH
ssl-default-server-options no-sslv3
defaults
log global
option httplog
retries 3
timeout client 5
timeout connect 5
timeout server 5
listen http-in
bind x.x.x.x:80
mode http
default_backend www_redit
listen https-in
bind x.x.x.x:443 ssl crt /etc/certs/server_2015.pem
mode http
acl samson_vpn_gateway src 10.8.0.1
acl missing_nagios_slash path_reg -i ^/nagios3[^/]*$
acl missing_cacti_slash path_reg -i ^/cacti[^/]*$
acl missing_dradis_slash path_reg -i ^/customers[^/]*$
redirect code 301 prefix / drop-query append-slash if
missing_nagios_slash
redirect code 301 prefix / drop-query append-slash if
missing_cacti_slash
redirect code 301 prefix / drop-query append-slash if
missing_dradis_slash
acl is_nagios path_reg -i /nagios3/
acl is_cacti path_reg -i /cacti/
acl is_dradis path_reg -i /customers/
#VPN Access Only
use_backend services if is_nagios samson_vpn_gateway
use_backend services if is_cacti samson_vpn_gateway
use_backend dradis if is_dradis
default_backend corp_site
listen corp_site
mode http
log global
option httpclose
source 0.0.0.0 usesrc clientip
option forwardfor
server websites01 172.16.0.10:80 check inter 3000 fall 3
server services1 172.16.0.5:80 check inter 3000 fall 3
listen www_redit
mode http
redirect scheme https
This should do the trick for you you may want to try putting your reqrep
in or play around with the acl list and re-test with your Headers but
I've got mine built with TProxy enabled.
~Scott
On 17/03/2015 15:36, Sean Patronis wrote:
I seem to be having an interesting issue with forced ssl redirects in
Haproxy 1.5.11
Sorry if this sounds clear as mud, but here goes:
When I load a domain that is served by haproxy that is supposed to
force https, it initially forces the connection to be https (if you
attempt to connect over http), but I get a Mixed content warning when
it attempts to load another url that is based on the same domain. If
I allow the mixed content through the browser, it does not get
redirected to https. I am sure I just have something configured
incorrectly, but I am not sure where.
I go to URL:
https://localcaleb.test123.com/apps/test123/test.html
inside the test123 app it makes a protocol-less request to another app
which ends up using http (since the backend is http balanced) using
this URL:
http://localcaleb.test23.com/apps/testgw/login.jsp
Since the we have a redirect for ssl in place, shouldn't the request
get forced to https? It worked this way when apache was acting as our
SSL reverse proxy. What am I doing incorrectly? If I allow mixed
content in the browser, the haproxy logs show that it indeed connects
over port 80 without getting redirected to 443.
here is the fontend:
frontend localcaleb.test123.com ## local Backends
bind 10.0.60.5:80
bind 10.0.60.5:443 ssl crt /etc/certs/test.bundle no-sslv3
ciphers
ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV3:!eNULL
redirect scheme https if !{ ssl_fc }
option http-server-close
acl is_apps_match url_beg /apps/
use_backend caleblocal.test123.com if is_apps_match
default_backend caleb.test123.com
here are the relevant backends:
backend caleblocal.test123.com
reqrep ^([^\ ]*)\ /apps/(.*) \1\ /\2
server caleb-pc.staff.test123.com 192.168.166.182:8080 weight 50
check
server maint maint.test123.com:81 check backup
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
backend caleb.test123.com
reqrep ^([^\ ]*)\ /apps/(.*) \1\ /\2
server caleb 10.0.3.216:80 weight 50 check
server maint maint.test123.com:81 check backup
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
Thanks.
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
