Help needed understanding abns@XXXXX

[jradxl]

Please can someone explain, or point me in the right direction to understanding Abstract Name Sockets as used in Haproxy.

I see many references in haproxy.cfg posts with entries like

abns@haproxy-clientcert
abns@haproxy-tcp-normal
abns@haproxy-tcp-clientcert

But I have no idea where the string after the @ is coming from.
It may be that people are posting truncated haproxy.cfg configs, so I can’t understand it.
Or these are defined somewhere (on a Linux Server) outside of haproxy.cfg.

Reference used:

Force SSL renegotiation on subdomain change using wildcard certificate

Hi, I’m using haproxy as an SSL terminator and SNI based service selector for my family server. Some of the subdomains use client side certificate, some of them not. Some of them are TCP, others are HTTP. For me haproxy is a convenient solution for SSL termination, authentication and even HTTP/2 support for my dummy embedded servers, alarm system, openvpn (over tls) and nextcloud instance. (A lot of things, except load balancing ) My problem with switching subdomain in a browser…

[lukastribus]

Those configurations are complete.

Like unix domain sockets, abstract name space sockets are just another type of sockets, which you can bind and connect to.

For example, in this haproxy configuration the backend verif-none accesses a frontend fe-ssl-normal of haproxy itself:

backend verif-none
 server recir abns@haproxy-normal

frontend fe-ssl-normal
 bind abns@haproxy-normal

The same could be done with a unix socket:

backend verif-none
 server recir /var/haproxy-normal

frontend fe-ssl-normal
 bind /var/haproxy-normal

Or, of course, a IP socket:

backend verif-none
 server recir 127.0.0.1:999

frontend fe-ssl-normal
 bind 127.0.0.1:999

Unix sockets, because they are actually in the filesystems, have some challenges with permessions, chrooting and chowning (when haproxy is dropping privileges). Abstract name space sockets are simpler to handle because filesystems permissions are not involved.

Think of it as a replacement for a sockets on free ports on 127.0.0.1.

For example in the configuration you linked, put it into a text editor and:

• replace abns@haproxy-normal with 127.0.0.1:10001
• replace abns@haproxy-clientcert with 127.0.0.1:10002
• replace abns@haproxy-tcp-normal with 127.0.0.1:10003
• replace abns@haproxy-tcp-clientcert with 127.0.0.1:10004
• replace abns@haproxy-error with 127.0.0.1:10005

and the config as well as abns sockets will start making sense. It’s just a quite complex haproxy configuration so it’s not ideal to use it to learn about abns or unix sockets for the first time.

[jradxl]

Thanks very much for your detailed explanation…
It took a number of reads before I got it!
It never occurred to me that a backend could feed a frontend. Now I understand the reason some examples refer to them as loopbacks.
Since we wrote, I’ve now seen examples of Unix and IP Socket methods
Thanks again