relayd with multiple pools

Hello list, following relayd setup exists in prod: relay int_health_check { listen on 127.0.0.1 port 78 protocol http_relay forward to port 80 mode roundrobin check http "/" code 200 forward to port 80 mode roundrobin check http "/" code 503 forward to

Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

On Wed, Nov 23, 2016 at 01:35:17PM -0500, Jiri B wrote: > I was using ssh socks5 tunnel (-D) today and I saw many: > > channel 4: open failed: administratively prohibited: open failed > > messages. It seems non-resolvable hostnames on my gw (ie. end of ssh > socks5 tunnel) is passed to

Re: Making sense of ktrace

"Andy Bradford" writes: > Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: > >> The stack may indeed be too damaged--I get the following but it >> doesn't look very helpful: > > More likely the symbols were stripped. > > Assuming this was installed from

Re: Making sense of ktrace

Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: > The stack may indeed be too damaged--I get the following but it > doesn't look very helpful: More likely the symbols were stripped. Assuming this was installed from sources, edit conf-cc and add -g, then edit conf-ld and remove

Re: umb(4) connection issues

On Wed, Nov 23, 2016 at 08:37:04PM +0100, Ingo Feinerer wrote: > Indeed, it works for me when an appropriate (default) route is manually > added and the listed DNS entries are manually set in /etc/resolv.conf. I forgot to mention about DNS. The script I came up with just grabs the values from the

Re: Making sense of ktrace

On 11/23/16 1:16 PM, Otto Moerbeek wrote: On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote: Hi all, I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs fine on 5.9 i386. I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't appear to be w^x

Re: Making sense of ktrace

On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote: > Hi all, > > I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs > fine on 5.9 i386. > > I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't > appear to be w^x related. To be sure I've

Re: umb(4) connection issues

On Tue, Nov 22, 2016 at 12:06:30PM -0800, Bryan Vyhmeister wrote: > On Tue, Nov 22, 2016 at 06:14:28PM +0100, Ingo Feinerer wrote: > > --8<- > > umb0: flags=8851 mtu 1500 > >

Making sense of ktrace

Hi all, I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs fine on 5.9 i386. I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't appear to be w^x related. To be sure I've mounted that partition with wxallowed. Here are the last few lines from

Re: VMM with Hapertown?

On Wed, Nov 23, 2016 at 01:03:07PM -0500, alexmcwhir...@triadic.us wrote: > I have some systems with Hapertown CPUS that support VT-x, but not EPT. Does > vmm currently require EPT to work? > for the time being, yes.

unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

I was using ssh socks5 tunnel (-D) today and I saw many: channel 4: open failed: administratively prohibited: open failed messages. It seems non-resolvable hostnames on my gw (ie. end of ssh socks5 tunnel) is passed to client as "prohibited" event. This seems odd and confusing. GW is an

VMM with Hapertown?

I have some systems with Hapertown CPUS that support VT-x, but not EPT. Does vmm currently require EPT to work?

[FOSDEM] [CFP] FOSDEM 2017 - Distributions Devroom - Extended

FOSDEM 2017 - Distributions Devroom Call for Participation (new deadline) The Distributions devroom will take place 4 February, 2017 at FOSDEM, in room K.4.601 at Université Libre de Bruxelles, in Brussels, Belgium. Distributions are more than just hosted collections of software from various

Re: Why not use malloc S by default?

On 2016-11-23, Philippe Meunier wrote: > Does anyone know of a relatively common program for which S > is a human-noticeable performance hit? vim with syntax highlighting. As a simple example just opening a file, the visible effect is a small extra delay, and easy

Re: strange behaviour with route-to, default route, and ping -I

Isn't that because your pings aren't originating from em0:network? Your rule need to apply in order to work, and the originating ip of the ping will not be correct in the first place, and neither does the ping come in on em0, as you state in the rule. "if incoming packets on em0 matches

Re: strange behaviour with route-to, default route, and ping -I

On Mon, Nov 21, 2016 at 12:10 PM, Stefan Sperling wrote: > On Mon, Nov 21, 2016 at 10:43:17AM -0500, Kenneth Gober wrote: >> I get the impression that route-to is applied when a packet enters the >> router, >> e.g. as part of a "pass in" rule, and that it is used to forcibly

Re: Why not use malloc S by default?

On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote: > Otto Moerbeek wrote: > >It is not a problem of crashing or not, S does incur a performance hit > >that we are not willing accept by default. > > I've seen this claim several times on this mailing list over the past > few years

Re: Why not use malloc S by default?

Otto Moerbeek wrote: >Here the difference is even bigger (about 68%). I think that shows >enough why S isn't the default (apart from buggy third party >software). Fair enough. Cheers, Philippe

Re: Why not use malloc S by default?

On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote: > Otto Moerbeek wrote: > >It is not a problem of crashing or not, S does incur a performance hit > >that we are not willing accept by default. > > I've seen this claim several times on this mailing list over the past > few years

Simple question on routing for IPSEC

Hi, Sorry for the dumb question but I'm suffering from config-writer's block ! OpenBSD6 if it makes any difference to the answers. Let's say I've got the following in ipsec.conf on my local gateway : "ike esp from 198.51.100.0/24 to any" Given that "any" is a catch-all, how do I, for

Re: Why not use malloc S by default?

Otto Moerbeek wrote: >It is not a problem of crashing or not, S does incur a performance hit >that we are not willing accept by default. I've seen this claim several times on this mailing list over the past few years but does anyone have actual data about it? How much of a performance hit is it

Re: Why not use malloc S by default?

On Tue, Nov 22, 2016 at 10:18:32PM +0100, Benjamin Baier wrote: > On Tue, 22 Nov 2016 19:44:48 +0100 > "minek van" wrote: > > > So why isn't "S" enabled by default? It is the "most secure" solution for > > the > > malloc settings, no? > > Or are there still programs that