Re: ModSecurity: First integration patches

On Tue, Apr 18, 2017 at 11:55:46PM +0200, Aleksandar Lazic wrote: > Why not reuse the upcoming http/2 format. > HTTP/2 is *easy* to parse and the implementations of servers are growing? Are you kidding ? I mean you want everyone to have to implement HPACK etc ? > I know this is still on the todo

Re: ModSecurity: First integration patches

Am 18-04-2017 15:10, schrieb Willy Tarreau: On Tue, Apr 18, 2017 at 02:59:20PM +0200, Christopher Faulet wrote: Le 18/04/2017 à 14:40, Willy Tarreau a écrit : > On Tue, Apr 18, 2017 at 12:15:20PM +0200, Christopher Faulet wrote: > > I finally took the time to review your patches, mainly the

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 02:50:45PM -0400, Mark S wrote: > On Tue, 18 Apr 2017 09:19:44 -0400, Slawa Olhovchenkov > wrote: > > > Today I am got this issuse on all 3 haproxy different hosts > > simultaneously (about 07:38:57 UTC I am got 'kernel: sonewconn: pcb > >

Re: time wrap caused kevent infinite loop

On Tue, 18 Apr 2017 09:19:44 -0400, Slawa Olhovchenkov wrote: Today I am got this issuse on all 3 haproxy different hosts simultaneously (about 07:38:57 UTC I am got 'kernel: sonewconn: pcb 0xf80040f781d0: Listen queue overflow: 1537 already in queue awaiting acceptance

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 05:18:13PM +0300, Slawa Olhovchenkov wrote: > > Now the remaining questions are : > > - how is it possible to have such a large timeout in the timer queue > > - why doesn't the situation fix by itself on the next millisecond when > > it's not supposed anymore to be

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 03:48:12PM +0200, Willy Tarreau wrote: > On Tue, Apr 18, 2017 at 04:19:44PM +0300, Slawa Olhovchenkov wrote: > > Today I am got this issuse on all 3 haproxy different hosts > > simultaneously (about 07:38:57 UTC I am got 'kernel: sonewconn: pcb > > 0xf80040f781d0:

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 03:48:12PM +0200, Willy Tarreau wrote: > > I am don't know how to add loging to ev_kqueue.c for print > > now_ms/exp/other stuff. > > Just after assignment of timeout.tv_sec/nsec, you could do something > like this : > > if (timeout.tv_sec < 0 || timeout.tv_nsec < 0 ||

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 04:19:44PM +0300, Slawa Olhovchenkov wrote: > Today I am got this issuse on all 3 haproxy different hosts > simultaneously (about 07:38:57 UTC I am got 'kernel: sonewconn: pcb > 0xf80040f781d0: Listen queue overflow: 1537 already in queue > awaiting acceptance (564

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 03:06:08PM +0200, Willy Tarreau wrote: > On Tue, Apr 18, 2017 at 03:53:29PM +0300, Slawa Olhovchenkov wrote: > > now_ms posible wrap (by design). > > As result delta_ms calcultaed as `TICKS_TO_MS(tick_remain(now_ms, > > exp)) + 1` can be negative. This caused negative > >

Re: ModSecurity: First integration patches

On Tue, Apr 18, 2017 at 02:59:20PM +0200, Christopher Faulet wrote: > Le 18/04/2017 à 14:40, Willy Tarreau a écrit : > > On Tue, Apr 18, 2017 at 12:15:20PM +0200, Christopher Faulet wrote: > > > I finally took the time to review your patches, mainly the second one, > > > about > > > the sample

Re: time wrap caused kevent infinite loop

On Tue, Apr 18, 2017 at 03:53:29PM +0300, Slawa Olhovchenkov wrote: > now_ms posible wrap (by design). > As result delta_ms calcultaed as `TICKS_TO_MS(tick_remain(now_ms, > exp)) + 1` can be negative. This caused negative > timeout.tv_sec/timeout.tv_nsec, failed kevent() (EINVAL) and infinite >

Re: ModSecurity: First integration patches

Le 18/04/2017 à 14:40, Willy Tarreau a écrit : On Tue, Apr 18, 2017 at 12:15:20PM +0200, Christopher Faulet wrote: I finally took the time to review your patches, mainly the second one, about the sample fetch. I think it would be pity to introduced such complex sample fetch. All parts, except

Re: resolvers default nameservers ?

Bingo - that's exactly what I'd hope for. The default default could be /etc/resolv.conf's nameservers (or eg; chroot context's equivalent), I grok that the runtime is different than parsetime, which makes parsetime the right time to get at the system's info as default. Dunno if there are any

Re: [PATCH]: CLEANUP

On Sat, Apr 15, 2017 at 08:09:41AM -0600, Jim Freeman wrote: > trivial typo in log.c applied, thanks Jim. Willy

time wrap caused kevent infinite loop

now_ms posible wrap (by design). As result delta_ms calcultaed as `TICKS_TO_MS(tick_remain(now_ms, exp)) + 1` can be negative. This caused negative timeout.tv_sec/timeout.tv_nsec, failed kevent() (EINVAL) and infinite loop.

Re: ModSecurity: First integration patches

On Tue, Apr 18, 2017 at 12:15:20PM +0200, Christopher Faulet wrote: > I finally took the time to review your patches, mainly the second one, about > the sample fetch. I think it would be pity to introduced such complex sample > fetch. All parts, except the HTTP headers, are already available in >

Re: ModSecurity: First integration patches

Le 12/04/2017 à 10:49, Christopher Faulet a écrit : Le 11/04/2017 à 10:49, Thierry Fournier a écrit : Hi list I join one usage of HAProxy / SPOE, it is WAF offloading. These patches are a first version, it have some limitations describe in the README file in the directory contrib/modsecurity.

Re: Certificate order

On 04/18/2017 11:52 AM, Willy Tarreau wrote: > Hi Daniel, > > On Tue, Apr 18, 2017 at 11:25:43AM +0200, Daniel Schneller wrote: >> Hi! >> >> Not being very familiar with the code, so I thought I'd ask before something >> changes unexpectedly :) >> I asked about certificate ordering a while ago,

Re: Certificate order

Hi Daniel, On Tue, Apr 18, 2017 at 11:25:43AM +0200, Daniel Schneller wrote: > Hi! > > Not being very familiar with the code, so I thought I'd ask before something > changes unexpectedly :) > I asked about certificate ordering a while ago, too, and I seem to remember > (and we currently rely on

Re: Certificate order

Hi Daniel, Yes, I understand your concern. I don't know if haproxy developers are willing to accept this change. Personally I think it is a good idea, because as it is now a sysadmin cannot ensure ordering of a specific wildcard before some domain specific one, whereas with my patch you are in

Re: HaProxy Hang

Hi David, On Tue, Apr 18, 2017 at 10:33:40AM +0100, David King wrote: > Hi All > > Just like to confirm Willy's theory, we had the hang at exactly the time > specified this morning. I could recycle myself in a new church of which I would be the prophet... well maybe it already exists, we have

Re: HaProxy Hang

Hi All Just like to confirm Willy's theory, we had the hang at exactly the time specified this morning. Sadly due to a bank holiday yesterday in the UK, we didn't set up the truss and monitoring before the hang occurred. Was the hang seen by everyone? Thanks Dave On 6 April 2017 at 14:56,

Re: Certificate order

Hi! Not being very familiar with the code, so I thought I’d ask before something changes unexpectedly :) I asked about certificate ordering a while ago, too, and I seem to remember (and we currently rely on this) that exact domain matches are “weighted higher” than wildcard matches on purpose,

Re: Please

Guys, eventhough I admit sometimes it can be fun, you make my life easier if you don't respond to spam (or at least remove the contents from the body before replying) because in order to maintain the anti-spam filtering efficient, I need to have a clear distinction between spam and ham based on

Re: resolvers default nameservers ?

On Fri, Apr 14, 2017 at 4:58 PM, Jim Freeman wrote: > The "resolvers" section doc discusses default values for all its > paramaters except "nameservers". > > If I have a on-line "resolvers" eg; > > "resolvers default" > > with no parameters listed, are the system (or context