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.
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:
server recir abns@haproxy-normal
The same could be done with a unix socket:
server recir /var/haproxy-normal
Or, of course, a IP socket:
server recir 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.
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