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.
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:
The benefits of this method versus an SMI-S method are simple:
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:
pg_hba.conf files
locate pg_hba.conffind /usr/apps -name pg_hba.confkillall -HUP progresql orps axwl|grep progresql; kill -HUP (the PIDs shown by that command)ps -ef|grep progresql; kill -HUP (the PIDs shown by that command)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)
I recently added quoting to the %JAR% (and equiv) in BAT files to survive spaces in pathnames
Chris found onsite that if the pathname for a vict.jar in DOS has a space, the VICT.BAT convenience BAT file might get confused in some circumstances. Embarrassing as that is, it’s now fixed.
Thanks, Chris, again!
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:
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:
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.
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.
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.
The problem I mentioned in version 1.0.46, wherein the bna://, OCI, and other protocols were reporting “unknown protocol: bna” or “unknown protocol: osmsql”. It seems that I had indeed butchered a search path, but it’s one burned into the main application.
Fixed now, should work fine 🙂
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:
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
The consistent recommendation in examples and blog posts to collect zone information for nicknames looks like this:
plink.exe -l username -pw password IP.IP.IP.IP zoneshow > IP.IP.IP.IP.zoneshow
For example:
plink.exe -l scott -pw tiger 192.168.1.1 zoneshow > 192.168.1.1.zoneshow
Despite this, users still feel that “grabbing the log from putty is good enough”. That actually costs additional work, and mores, it means that greater-than-zero work is needed, and that seems to be a task that is fairly complex to do onsite with a customer when you’re jet lagged, and grumpy, and got zero sleep because the (m)hotel you slept in at company expense policy was beside a railway track for efficiency. I mean, c’mon, we all know that the best TV remote-control is the one with only one button, why can’t nicknames be that easy? Although it bugs me that directions cannot be followed, it bugs me even more that I need to be so precise. Why can’t I just skip the same stuff I skip manually?
So I did that: fibrechannel-parsers added the ability to skip any preamble that ends in “alishow” or “zoneshow” in order to accept the zoning text commonly offered for nicknames.
In order to confirm that an earlier release is never used if found during discovery, a testcase was added to vitools to confirm that the fcparsers jar includes the new handling of putty-dump-ish preamble that apparently occurs even when directions are perfectly followed and “collect zone or alias information non-interactively and no-never-ever use putty” is the rule that gets missed. vict.jar and vw4tool.bat should both be a bit more tolerant.
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.