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

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)

How to Collect DCNM and BNA Data via SMI-S Interface

OK, I need to come clean on one thing: this article isn’t about SMI-S per-se, but about connecting via CIM-XML. The thing is, “what is CIM-CML?” When a client connects to, let’s say, BNA, it can talk CIM-over-HTTP, CIM-over-HTTPS, or CIM-over-RMI. In hindsight, maybe I should have focused on RMI, but I had reasons. Had I titled this “…Data via CIM-XML over HTTP”, I would anticipate glazed eyes, and no real up-take on why this matters.

The trick is: it doesn’t matter a whole lot. …but it’s there if you need it, simply because I had it around.

We typically draw information from BNA (and alpha-quality in DCNM) by speaking directly to the underlying database, like this:

wpg_div_wp_graphviz_2

So normally, that’s a command such as:

java -jar vict.jar -N bnapsql://bna.example.com/
java -jar vict.jar -N dcnmsql://dcnm.example.com/ (again, needs QA)

These use the BNADatabase passwords, not the user’s password with which he is more familiar. These are typically hindered by ACL (the evil “pg_hba.conf”, all 4 of them).

The thing is, this method (in BNA) gets the data that isn’t available by SMI-S… err… CIM-XML. This gets the aliases that are not zone aliases. If you don’t recognize the difference, or remember “the McData way”, understand that some data isn’t available.

So there I was working on a DCNM Writer for a customer. It’s been taking way too long, and in order to test, I had added a DCNM CIM-XML client to the parsers. I needed something to bang on the DCNM and see what it had for when I try to push changes into it.

I needed this:

wpg_div_wp_graphviz_3

I decided to complete a functional BNA client (alpha), together with a DCNM client, and make those available to both vict.jar (VW3) and (VW4) vw4tools.jar via underlying FibreChannel-Parsers. They’re used like this:

java -jar vict.jar -N bnacql://bna.example.com/ (this one needs QA)
java -jar vict.jar -N dcnmcql://dcnm.example.com/
java -jar vw4tools.jar -N bnacql://bna.example.com/ (this one needs QA)
java -jar vw4tools.jar -N dcnmcql://dcnm.example.com/

The abbreviation for the protocol is BNA/DCNM, followed by CQL, the CIM Query Language, which is actually similar to SQL92 (Language, not Microsoft product). Microsoft has a variant for the WMI called WQL. If you like, you can be more explicit able the defaults:

java -jar vw4tools.jar -N dcnmcql://scott:T1ger@dcnm.example.com:5988/cimv2

Of course, you’d want a -o or -n to make use of the collected data, and you’ll see collected nicknames show up as NicknameParser counts (these data sources feed a text stream that is parsed by NicknameParser). vw4tools has full capability to –pattern itself into some upper-level entities, or just spit out fcports.

…and that’s the power of what I’ve done: the BNA and DCNM portions are merely small layers over the underlying capability. I could replace the vCenter collector with a CIM-XML client, or use that to interrogate various storage devices, but I assume VirtualWisdom4 Discovery will eventually do that for us in a much more Quality-check and code-reviewed and reliable manner.

As a reminder, the things I build are intended towards the installation timeframe, where a few hiccups are accepted so long as the task is completed. I don’t necessarily feel these tools would be used beyond installation day.

Revision 670 – BNA Client Migrated

In this revision, minor changes were done to move the BNA client code outside of the non-public source base and into the public source base at BNAPURLConenction.java. This allows for external audit of the code and may improve trust and reduce concern. Also, if I’m doing something very wrong, others may notice.

The project retains all the test cases involving this and other parsers, so functionality is verified retained, there should be very little change in behavior.

The BNA backend-database client was added 21 months ago (Revision 345 – How to Read Nicknames from a BNA Server) and was improved 3 months later (Revision 450 – bnapsql Improvements).

Revision 665 – Handle Brocade Hanging F-ports

The underlying fibrechannel-parsers project added the ability to properly handle H{xxx} markup, which seems to be Brocade marking out Hanging fabric members (disappeared, never rejoined). In vitools, a testcase confirms functionality absorbed into vict.jar “-N” behavior.

In short, the ability to ignore hard-zoning was improved to get the WWPN from a hanging member as well.

Revision 652 – Just a Few More Debug Statements

Built using fibrechannel-parsers v0.3.49 which adds a few debugger options to ZoneParsers — the quick summary on that is when things go sideways, I might be able to get a clue more quickly rather than “pulling teeth” to get screen caps (understanding that our users tend to be in closed-off VLANs and such).

Builds against JDK-1.6 to JDK-1.8.

A certain Texan asked for an alternative query, and even though that thread went a little quiet, a different query statement gets run against a BNA server when using the bna:// or bnapsql:// protocols in a “-N” or “–nickname=” statement to VICT when the java option -Ddebug.carleton=true is used.

Revision 648 – alishow/zoneshow Parser Safely Ignores HardZoning, Multiple cfg:

Hard-zoning records are no longer an issue in the alishow parser.

The external fibrechannel-parsers (fcparser.jar) recently safely ignored multiple cfg: sections, but was still hanging up on hard zoning records.

hard-zoning records — basically “the zone includes blade X, port Y” — not even recommended by Brocade, is occasionally seen in “in the wild”, typically in environments merged into the current one through corporate merger/acquisition of an older SAN. Few support the additional effort and logistical challenge of maintaining hard-zoning of any significant size. It’s those “attritioning out” systems that administrators are nicely letting be until they roll off their life-cycle into recycle.

For now, those hard zoning records would stop the parser immediately. Now, the parser ignores them, still reads the zoning record if available, and carries on.

Revision 602 – Split and Build with external Parsers, Solved a Parse issue

In this revision, the parsing code is now external; it has been split out to “fcparsers.jar” from fcparsers-java rpm visible at github.com/chickenandpork/fibrechannel-parsers/ … this was done to improve code visibility and to allow bug reports to be created more closely to the specific piece of code involved.

In doing so, I also chased down a parsing issue in that the following block would produce a nickname short:

alias: NASMany_654321
                10:00:00:00:c9:44:44:10; 10:00:00:00:c9:44:44:11
                10:00:00:00:c9:44:44:20; 10:00:00:00:c9:44:44:21
                10:00:00:00:c9:44:44:30; 10:00:00:00:c9:44:44:31

Results:

10:00:00:00:c9:44:44:11,"NASMany_654321"
10:00:00:00:c9:44:44:20,"NASMany_654321"
10:00:00:00:c9:44:44:21,"NASMany_654321"
10:00:00:00:c9:44:44:30,"NASMany_654321"
10:00:00:00:c9:44:44:31,"NASMany_654321"

… clearly missing “10:00:00:00:c9:44:44:10” (and yes, per the weak consuming parser to which we send this result, no space can be between the WWN and the alias).

That was resolved by fixing the byacc parser code. All six members now show up.

Revision 365 – Inflight BNAPSQL Changes

Revision 365 improves the BNAPSQL Client to avoid null nicknames, and avoid quoting those nicknames that are already quoted.

This was performed live with a customer on the conference call; really great debugging experience.

As a reminder:

 java -jar vict.jar --nickname=bnapsql://user:pass@server:port/resource

where the default is:

 java -jar vict.jar
   --nickname=bnapsql://dcmadmin:passw0rd@localhost:5432/dcmdb

…and if you just want to spit the nicknames right back out from two servers:

java -jar vict.jar
--nickname=bnapsql://server1/
--nickname=bnapsql://server2/
--nicknameout=output.csv