RE: possible bug with CumReq info stat
There is no SSL protected repo. I'm surprized that you found the haproxy.org site slow, usually it's reasonably fast. Are you sure you weren't cloning from 1wt.eu instead, which is the slow master ? Would it be possible to get the haproxy org on github to be synced with your repos. Haproxy.org is supposed to be synced. Github's haproxy account doesn't belong to me and is not an official one (and it's different). Since there is also a haproxy github-organisation behind this github fork, it does look like it would be an official mirror and I can see why it attracts bug reports on the github issue tracker for those repositories and merge requests on github instead of the mailing list. Thats bad, very bad. For anyone forking or mirroring a particular piece of code: please do not impersonate the author or the project. Make it abundantly clear that the mirror is unofficial (not only in the description or README, but in the title). I'm CC'ing Jeff Buchbinder since he seems to be the one merging real haproxy git back to this github fork. That might provide a nice SSL protected location. It will bring absolutely nothing I tend to disagree: 1) trees are replicated to multiple places Of course the actual replication would have to be protected as-well, not just the download from the mirror. SSH or HTTPS as a transport protocol will do that. and 2) the git structure by itself provides protection. I don't see how it can protect against a MITM'ed git mirror that is serving tainted repositories. However SSL would be even slower and more resource intensive. I believe the performance penalty of SSL is neglectable. Lets look at some numbers: From my box here I have about 55ms of RTT to git.haproxy.org and 115ms RTT to github.com (the latter crosses the atlantic). If I clone via unprotected HTTP from git.haproxy.org I need about 2 and a half minutes. If I clone via protected HTTPS from the github.com fork (which is not exactly the same, but not that different either) I need about 30 seconds. So although the RTT to github is about twice as much and we use HTTPS instead of HTTP, it still is about five times faster than git.haproxy.org. This is most likely due to the plain-HTTP usage instead of git-over-HTTP, as Warren mentioned. Do we absolutely need that kind of speed? No. I'm just saying that performance is not a showstopper for SSL, especially in this case. And would require a cert and careful maintenance. Correct, unless we would use something like github ourselfs. That would mean leveraging their platform for all those nice things like HTTPS and git-over-HTTP, without the actual maintenance burden. That requires, of course, trusting github. What this would also bring to the table is a bug-tracker with strong ties to git (but is of course github-proprietary). Regards, Lukas
Re: possible bug with CumReq info stat
All fair points. Too bad you don't have the haproxy org on github. It would be nice if that were a trustworthy source. With regard to the slowness, I am using the following remote config: $ git remote -v origin http://git.haproxy.org/git/haproxy-1.5.git/ (fetch) origin http://git.haproxy.org/git/haproxy-1.5.git/ (push) It looks like that server uses the dumb http protocol for git, which requires more roundtrips. $ curl -si http://git.haproxy.org/git/haproxy-1.5.git/info/refs?service=git-upload-pack | grep --binary-files=text '^Content-Type' Content-Type: text/plain -- this would be different in the smart protocol That may explain the slowness. Thanks, wt On Mon, Feb 2, 2015 at 9:40 AM, Willy Tarreau w...@1wt.eu wrote: On Mon, Feb 02, 2015 at 09:34:37AM -0800, Warren Turkal wrote: On Sat, Jan 31, 2015 at 4:57 AM, Willy Tarreau w...@1wt.eu wrote: There is no SSL protected repo. I'm surprized that you found the haproxy.org site slow, usually it's reasonably fast. Are you sure you weren't cloning from 1wt.eu instead, which is the slow master ? Would it be possible to get the haproxy org on github to be synced with your repos. Haproxy.org is supposed to be synced. Github's haproxy account doesn't belong to me and is not an official one (and it's different). That might provide a nice SSL protected location. It will bring absolutely nothing considering that 1) trees are replicated to multiple places, and 2) the git structure by itself provides protection. However SSL would be even slower and more resource intensive. And would require a cert and careful maintenance. Willy -- Warren Turkal
Re: possible bug with CumReq info stat
On Mon, Feb 02, 2015 at 09:34:37AM -0800, Warren Turkal wrote: On Sat, Jan 31, 2015 at 4:57 AM, Willy Tarreau w...@1wt.eu wrote: There is no SSL protected repo. I'm surprized that you found the haproxy.org site slow, usually it's reasonably fast. Are you sure you weren't cloning from 1wt.eu instead, which is the slow master ? Would it be possible to get the haproxy org on github to be synced with your repos. Haproxy.org is supposed to be synced. Github's haproxy account doesn't belong to me and is not an official one (and it's different). That might provide a nice SSL protected location. It will bring absolutely nothing considering that 1) trees are replicated to multiple places, and 2) the git structure by itself provides protection. However SSL would be even slower and more resource intensive. And would require a cert and careful maintenance. Willy
Re: possible bug with CumReq info stat
On Sat, Jan 31, 2015 at 4:57 AM, Willy Tarreau w...@1wt.eu wrote: There is no SSL protected repo. I'm surprized that you found the haproxy.org site slow, usually it's reasonably fast. Are you sure you weren't cloning from 1wt.eu instead, which is the slow master ? Would it be possible to get the haproxy org on github to be synced with your repos. That might provide a nice SSL protected location. wt -- Warren Turkal
Re: possible bug with CumReq info stat
Hi Warren, On Tue, Jan 27, 2015 at 03:04:16PM -0800, Warren Turkal wrote: The definition of the global.req_count at include/types/global.h line 109 is an unsigned int. The print code it treating it as a signed int. The attached commit fixes that. Thanks, I've applied it to both 1.5 and 1.6. Also, is there an SSL protected location for fetching the haproxy git repo whose cert is signed by a widespread CA? The haproxy.org site also seems to be pretty slow for git cloning. There is no SSL protected repo. I'm surprized that you found the haproxy.org site slow, usually it's reasonably fast. Are you sure you weren't cloning from 1wt.eu instead, which is the slow master ? Regards, Willy
Re: possible bug with CumReq info stat
BTW, the patch in the previous mail was based on the master branch of the haproxy-1.5 repo if that matters. Thanks, wt On Tue, Jan 27, 2015 at 3:04 PM, Warren Turkal w...@signalfuse.com wrote: The definition of the global.req_count at include/types/global.h line 109 is an unsigned int. The print code it treating it as a signed int. The attached commit fixes that. Also, is there an SSL protected location for fetching the haproxy git repo whose cert is signed by a widespread CA? The haproxy.org site also seems to be pretty slow for git cloning. wt -- Warren Turkal -- Warren Turkal
possible bug with CumReq info stat
The definition of the global.req_count at include/types/global.h line 109 is an unsigned int. The print code it treating it as a signed int. The attached commit fixes that. Also, is there an SSL protected location for fetching the haproxy git repo whose cert is signed by a widespread CA? The haproxy.org site also seems to be pretty slow for git cloning. wt -- Warren Turkal commit 2f4e2480139fdd976d9e9edef3fd582d50f21027 Author: Warren Turkal w...@signalfuse.com Date: Tue Jan 27 15:02:00 2015 -0800 Fix incorrect printf type. The value is defined in include/types/global.h to be an unsigned int. The type format in the printf is for a signed int. This eventually wraps around. diff --git a/src/dumpstats.c b/src/dumpstats.c index 1070ff4..b616478 100644 --- a/src/dumpstats.c +++ b/src/dumpstats.c @@ -2492,7 +2492,7 @@ static int stats_dump_info_to_buffer(struct stream_interface *si) Hard_maxconn: %d\n CurrConns: %d\n CumConns: %d\n -CumReq: %d\n +CumReq: %u\n #ifdef USE_OPENSSL MaxSslConns: %d\n CurrSslConns: %d\n
