Tag Archives: BNA

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

Posted on by
Reply

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

Posted on by
Reply

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.

Version 1.0.73 – Collect Nicknames via CIM-XML CQL Client

Posted on by

This edit allows two additional “protocol” values: instead of just http, ftp, bnapsql, dcnmsql, and the formats listed on FibreChannel-Parsers docs, this adds:

  • bnacql://user:pass@server:port/path to query a BNA server using CQL
    • ie bnacql://bna.example.com/
    • ie bnacql://scott:tiger@bna2.example.com:5988/cimv2
  • dcnmcql://user:pass@server:port/path to query a DCNM server using CQL
    • ie dcnmcql://dcnm.example.com/
    • ie dcnmcql://scott:tiger@dcnm.example.com:5988/brocade1
    • ie dcnmcql://customer:pass@dcnm.example.com/

For example, I’ve been hammering away at it using a command like this:

java -jar vict.jar -N dcnmcql://admin:adminpass@192.168.1.130/ -n nick.csv
… and I would see that the collection extracted 3 DeviceAliases.

The DCNM CQL client draws out Device Aliases, but I haven’t found fcaliases yet.

The BNA CQL client will draw out Zone Aliases, but not Aliases of the non-zone-alias sort.

Why? I needed a CIM-XML client for some work I was doing, and I had the code loosely working so that I could use it to test the other real deliverable. Since I had a DCNM client already, I split the Cisco-specific stuff out, and slotted in a BNA client. The DCNM client (via dcnmcql) is working just fine, but I don’t have a test server to beat up with the BNA client. It works in theory?

How is this useful? Not a whole lot, since VW4 will use a protocol like these to collect information, but I’d like to point out something:

this doesn’t need a license

This would actually let a customer check “will VW4 see all of my aliases?” which — as Application Engineers and Deployment Techs know — is actually a fairly long pole in the circus tent of VW4 deployments.

Version 1.0.46 – Check for Driver Availability During Build

Posted on by

In trying to catch more errors during build rather than runtime — i.e. even before the test cases are run — I’ve extended the behavior of “vict.jar –check” to check its own driver configs and to test-load the various handlers.

I’m still plagued by an error in bringing a driver online for nicknames. In this example, a customer — A CUSTOMER! Augh! — found the error “unknown protocol: bna”. A CUSTOMER found this! Crapola. So I went looking, and still chasing this one, but I know for certain that the drivers are all checked and present during build, and that they can be loaded. It’s somewhere else in the search process.

Revision 670 – BNA Client Migrated

Posted on by

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 652 – Just a Few More Debug Statements

Posted on by

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 365 – Inflight BNAPSQL Changes

Posted on by

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