Allow preserving abstract namespace sockets address length about haproxy

[Tristan971]

Digging a bit more, this seems like it's also been reported a long time ago here (in 1.5) https://haproxy.formilux.narkive.com/WkdV7fGj/abstract-namespace-sockets-handling

[wtarreau]

I think I'd be OK with changing the default at least because as you say it looks like the rest of the ecosystem has chosen that option, but we need to be sure not to break the old one. If some users have already padded their addresses in their servers to receive connections, or have passed the option to socat, it will suddenly stop working. Or maybe we should just create a new family that is not padded (e.g. abns2) ? After all that's the point of using different address families, we're in some sort changing the address family here. BTW, I was also concerned with the risk that some older kernels might possibly not support this, but I checked, and in kernel 2.1.131 it already used the advertised size so from this point that's OK.

[Tristan971]

Agreed on both points; as you'll see on the ML, I took a tunable approach as I'm sure some people manually tweaked their other programs already.

As for changing the default, I'd certainly not complain either :)

Or maybe we should just create a new family that is not padded (e.g. abns2)

I considered that too, but in the end I figured that it's a bit overkill for a niche-enough feature vs a tunable that changes the default value, especially with how many bind families already exist

[lukastribus]

I agree with the non-invasive patch on the ML.

Changing the default on the other hand will break old configurations, configurations that have been in active use, otherwise those previous conversations wouldn't have come up on the issues tracker and mailing list in the first place.

So yes, I'd say changing the default behavior of the abns@ address family prefix is not possible.

If the goal is to end up with a abstract namespace address family that doesn't default to zero padding, then we will have to deprecated the abns@ address family entirely for one LTS cycle or two along with the introduction of new address family prefix.

[Tristan971]

So yes, I'd say changing the default behavior of the abns@ address family prefix is not possible.

While I don’t think it’s mandatory, I don’t agree that it’s impossible or even undesirable.

It’d be reasonable enough to add a notice, which is then increased to a warning in a subsequent release, until a changing-default release.

That said, no matter the default, HAProxy will have to support changing behavior in perpetuity, like socat does and the proposed patch enables.

As for the default, I’m honestly neutral in the way to go because I think it’s advanced and niche enough that:

• no change: requiring a flag forever for « new » behavior is an okay cost
• change: requiring a flag be added to revert to « old » behavior not changed for 10 years is also ok

In both cases, the specifically affected crowd can honestly just « deal with it ». And that includes me if it doesn’t change.

But I don’t like the idea that known-suboptimal defaults are to be kept in software for BC alone.

They accumulate over the years, and then you end up with something like MySQL, where you absolutely need 30 lines of boilerplate config to get to a not-insane set of defaults.

That said, I don’t think the default value here is particularly good or particularly bad, and both seem acceptable to me. So this is more philosophical than on-topic… :)