How to Fix pg_hba.conf to Allow bnapsql:// to Read Nicknames

Posted on by

The bnapsql:// protocol was added over two years ago; this protocol connects to BNA’s backing database (progresql) and asks it directly for some information:

wpg_div_wp_graphviz_1

The benefits of this method versus an SMI-S method are simple:

  1. it doesn’t require a license fee to check or try
  2. it grabs both “zone aliases” and “aliases” (the “SMI-S” interface — CIM-XML — only shares “zone aliases”)

This worked fine until BNA-12.0.2 (including HPNA and CMCNE); after that, the vict.jar starts to report an error something like this:

FATAL: no pg_hba.conf entry for host “192.168.1.1”, user “dcmuser”, database “dcmdb”, SSL off
Please add the client’s IP address to the file
ie: host all all 0.0.0.0/0 md5

So what’s the problem?

pg_hba.conf is like a hosts.allow used in old UNIX: it lists those allowed to talk to the server. It’s like an Access-Control List.

In BNA-12.0.2, the standard entry was changed from:
host all dcmuser 0.0.0.0/0 md5
to:
#MIGRATION#host all dcmuser 0.0.0.0/0 md5

…so you can see that it’s merely been commented out, as well as an IPv6 equivalent. In short, we’ve lost access to the backing database due to a change in BNA’s ACL to better protect itself.

So what’s the solution?

Strange as it may seem, the error message holds the key to the solution:

Please add the client’s IP address to the file
ie: host all all 0.0.0.0/0 md5

Now, I’d never accuse anyone from not bothering to read the error message, no! 🙂 Seriously, this sort of error message seems like so much spewing TL;DR, and The problem is: which one? which pg_hba.conf? Did I get the correct one of two, three, or four?

Just like everyone else, I like to get stuff done and go home; in support of getting things done, without “throwing my peers under-the-bus too much”, here’s more detail about fixing this problem:

The vict.jar tries to give a hint with a filename, but that only works on Windows installs of a specific version. In short:

  1. find all the pg_hba.conf files
    • everything but windows: locate pg_hba.conf
    • everything but windows: find /usr/apps -name pg_hba.conf
    • windows: use whatever windows has this week as a search tool to find these files
  2. change each one, checking when changed
  3. you may need to SIGHUP the database server
    • on linux/UNIX/MacOSX/BSD/everything-but-windows: killall -HUP progresql or
    • on linux/MacOSX/BSD: ps axwl|grep progresql; kill -HUP (the PIDs shown by that command)
    • on UNIX (USL) and UNIX variants (including AIX): ps -ef|grep progresql; kill -HUP (the PIDs shown by that command)
    • windows: forget it: there’s no signal subsystem. Just restart the postgresql service every time. Yeah, that’s heavy-handed

There might be an easier way to find out which directory holds the pg_hba.conf file that matters, but it’s not consistent. I doubt it’s a huge benefit to knowing exactly which pathname on every system supported by progresql; rather, the method of finding it might be more efficient.

a few more links
(links also inline to survive printing)