Version 1.0.92 – vw4tool.bat repaired

Don pointed out that the vw4tool.bat was not working. It’s been resolved.

There was an edit in version 1.0.75 which quoted convenience BAT files for robustness. Unfortunately, this caused the conversion of vic.bat file into vw4tool.bat file to fail, so every vw4tool.bat was an exact copy of vict.bat.

The conversion is fixed, and vw4tool.bat should work as intended.

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.

Version 1.0.73 – Collect Nicknames via CIM-XML CQL Client

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.72 – Fix a Null Pointer Exception

This release is simply a bug fix: Chris Carlton gave the vict.jar a command that caused a parser to be not-sane; the resulting null propagated, and trashed out the entire parser.  Unfortunately, the exception cascaded to the array of parsers, breaking isolation and tearing down all the parsers.

This would affect both vict.jar and vw4tools.jar as both share the underlying FibreChannel-Parsers

I need to create wrapping exception blocks to stop repeats of the cascade, but in the short-term this one symptom is resolved in this release.  …with my apology.

Version 1.0.71 – SwappedNicknameParser

I created a specific instance of the NicknameParser as a convenience: I worked with a colleague on a limited environment wherein he could not run a “awk -f swap-1-2.awk” to swap columns, and wasn’t getting results from the parser.  To be honest, it took us both too long to realize that the simple WWPN/Nickname order was swapped to Nickname/WWPN.

I hate being surprised by software when there’s a deadline; as well, I like to cater to jet-lagged Application Engineers and anyone who “just wants to get the gig done”.

This adds a NicknameParser as a --nickname=file.csv;WWN=1;Nickname=0 but avoids having to explain that.  This situation is common enough, this addition just helps get it done with very little drawback.

FibreChannel-Parsers added the SwappedNicknameParser; vitools includes a test case to ensure that the fcparsers.jar picked up during the build includes the convince feature.

Version 1.0.58 – TSV Data parser

FibreChannel-Parsers project added a parser for Tab-Separated Values — my esteemed colleague ran into this, and it was a serious nuisance.  In the end, Ravi simply re-requested a different format, but I wondered: “how long would it take to simply add a TSV parser?”

Apparently not long.

The difference any user would see if that a TSVParser is included in the list of parsers attempted.  If there is TSV, it’ll be parsed.  the same “URL;WWN=0;Nickname=4” -sort of nomenclature can be used to tell the parser “the WWPN is the first column (#0), the nickname/alias is the 5th (#4)”.  The TSVParser uses either a tab or a space as whitespace-separated values.

This parser is available to both vw4tools and vitools.

vitools adds a check to ensure that every build includes this parser.

Version 1.0.51- SubstituteWithSNICK fixed

I fixed a NullException in the -S function to vict.jar

The -S (Substitute with SNICKs) is similar to the -f (filterOut) as follows:

FilterOut (-f) removes all nicknames that are “predictable” or “provided” in VW3, and most likely provided by the VW3.x system to take the place of empty nicknames. Recall that VW3 will show an alias if available, an FCID is there’s no nickname, or a WWPN if no FCID is granted to a FLOGI. This means nicknamed devices show nicknames, but F-ports lacking nicknames show FCIDs, and ISLs (wherein no FCID is available) show WWPNs of the remote switch. FilterOut removes those predictable values, so that only the nicknames not appearing to be WWPN, the name “nickname (ISL)”, nor FCIDs (5-digit and 6-digit) are given. It can reproduce the original imported nicknames.

The risk, of course, is that bogus nicknames can be artificially elevated in status. The “provided” nicknames are overwritten by VW3 as new ones are available. A WWPN re-FLOGIs and gets a new FCID, that redefines the FCID-based nickname. The VW3 system will not overwrite a user-provided nickname, however.

What happens when the user imports a FCID-based nickname? The VW3 system will not overwrite it, so the wrong FCID is shown instead of the correct one. There’s no strong indication that this is occurring: VW3 doesn’t track whether a nickname is being conveyed or generated/provided. Additionally, “use Key Aliases” turns off ALL aliases, treating VW3-provided nicknames like user-provided nicknames.

FilterOut avoids this, and it’s as simple as using after a -nickname= collection:

VICT.BAT -N bna://bna.example.com/ -f -n nicknames.csv

java -jar vict.jar -N bna://bna.example.com/ -f -n nicknames.csv

SubstituteWithSNICKs (-S) takes this one more step:

  1. filter it out
  2. if there is a SuggestedNickname (SNICK) (see http://github.com/chickenandpork/wwndesc/), replace it with that

This allows the user to remove all FCID nicknames and replace them. Storage devices, SVCs, even some NPIVs (hey, vConnect and UCS, I’m looking at you) can be swapped in, identifying, for example, the Chassis (002a6a) of a UCS.

it’s just as simple as FilterOut:

VICT.BAT -N bna://bna.example.com/ -S -n nicknames.csv

java -jar vict.jar -N bna://bna.example.com/ -S -n nicknames.csv

or, verbosely:

VICT.BAT --nickname=bna://bna.example.com/ --suggestednicks --nicknameout=nicknames.csv

java -jar vict.jar --nickname=bna://bna.example.com/ --suggestednicks --nicknameout=nicknames.csv