More of the same.
I get some kind of hex number on 192.168.2.32:80 showing the HTTP daemon is working I guess but ArmoryQT is still throwing the same error.
EDIT: After looking through the forum, I found this which is the exact same setup I have but nginx is listening on port 80 instead of 9002.
https://bitcointalk.org/index.php?topic=1617087.20His issue was specifically *nix server to Windows client
No? I thought it was only required for many client. I might have misunderstood the release notes.
Will put behing nginx and report back.
DB only has a fcgi layer (this is what PHP uses, as an example). You need consider the DB as something like a MySQL server. It isn't meant to be exposed to the WAN directly, nor an insecure LAN, because it does not have the necessary code to allow users to setup networking rules nor load balancing. That's what the public facing daemons are for.
The DB is hardcoded to listen to localhost. You can change the FCGI listen port but not the IP. You need to run the daemon in front of it to allow clients to access it remotely.
Since this is FCGI, the client uses HTTP over the socket, which is why it is fairly easy to setup a daemon on top of it (and one of the advantages of CGI in general).
As a convenience feature, I also implemented FCGI at the client level, so that it may speak with a local DB without the need for the HTTP daemon in between.
The client will only speak FCGI if you let it run the default IP:port to connect to the DB. If you change any of those, it will revert to pure HTTP, which the expected daemon on the other side will convert to FCGI for the server's benefit. The server only speaks FCGI (which basically decorates HTTP packets with some meta data).
I guess this is an unresolved bug? Will try to run ArmoryQT from a Linux VM tonight as this guy seem to say that it works from Linux ArmoryQT to a Linux ArmoryDB/nginx/bitcoind setup.
Your best course of action is to participate to the 0.96 testing rounds to help me isolate and fix any bug on that front.
