Hi Jason,
> In further tests, I adjusted the bind line to the following (explicitly
> defining a second key)
> bind <ip>:443 ssl crt <nfs>/default.pem crt <nfs>/site2.pem crt
> <local> crt <nfs> strict-sni
>
> Accessing site2 with the above bind line worked correctly.
I'm not sure if its a good idea to load certificates from remote NFS
servers. What if haproxy starts when the NFS path is not yet available
or mounted? HAProxy will certainly not recover.
> Removing the 'site2.pem' from the bind line, leaving the <nfs> and
> <local> folders defined to be processed resulted in site2 dropping
> offline (due to the strict-sni).
> Copying the site2.pem back to the local folder, leaving it out of
> haproxy.cfg (and restarting the daemon) restored site2 to service.
So it all comes down to the combination of a generic path to a folder
and NFS.
> I'm not sure how to get enough debug data out of haproxy to determine
> what it's doing during init to determine if it's finding the key files
> on the NFS to pull in to it's running config, or anything else that
> could prove useful in further troubleshooting this.
>
> Any suggestions is greatly appreciated.
Run haproxy through strace during startup.
Something like
$ sudo strace /sbin/haproxy -db -f /etc/haproxy.cfg
Regards,
Lukas
