Tag Archives: Nickname

Version 1.0.87 – Zone-Voting Stage 1 More Versatile

Posted on by

Cisco’s output format changes — this is to be expected, it’s a text stream, not a structured markup, and I’m somewhat surprised it’s been static for this long.

Due to these changes, and the fact that FibreChannel-Parsers currently doesn’t offer zoning information from a cisco “show zones” which would allow it to replace the stage1 of a zone-vote, some quick changes were necessary to the AWK script that plays one of the adapting stage1, the “make it canonical” stage.

Usage remains the same, no changes in output or behavior.

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)

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

Posted on by

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

Posted on by

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

Posted on by

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.56 – Host-Munging Aggregation Patterns

Posted on by

vw4tools added host-munging to improve chances of pattern-based aggregation. This allows a derived hostname that’s slightly different than the hosts (to allow for enforced consistency) or to allow for some flexibility in the hostnames and entities.

This was created specifically for a situation where a customer had lowercase aliases for the A fabric, uppercase for the B fabric. Although this seems quite simple and straightforward, “A” and “a” are different letters, so the collection of SERVER44_HBA0 and server44_hba1 is much more difficult. The only host-munging enabled currently is:

–munge=host:touppercase

for example:  (patterns command line options edited out for clarity)

java -jar vw4tools.jar -N (source) --munge=host:touppercase -oresult.json

or:

java -cp vict.jar org.smallfoot.vw4.VirtualWisdom4ClientTool -N (source) -M host:touppercase -o result.json

The different might be better explained as OrderedTuples Output:

java -jar vw4tools.jar -N (source) -oOrderedTuples.csv
SERVER44,host,10000000c9123456,SERVER44_HBA0
server44,host,10000000c9123456,server44_hba1

This gives:

  • (host) SERVER44
    • (hba) SERVER44_HBA0
  • (host) server44
    • (hba) server44_hba1

java -jar vw4tools.jar -N (source) -M host:touppercase -oOrderedTuples.csv
SERVER44,host,10000000c9123456,SERVER44_HBA0
SERVER44,host,10000000c9123456,server44_hba1

This gives:

  • (host) SERVER44
    • (hba) SERVER44_HBA0
    • (hba) server44_hba1

You’ll see that the second line of OrderedTuples has an uppercase parent entity. The first non-munge result shows two hosts, each of which has one HBA; the second example shows one (uppercase) host that contains two HBAs.

This matches the user’s request for all host entities to be the uppercase version of the upper-/lower-/mixed-case HBA alias or storage alias.

To ensure that vw4tools includes this fix, vitools adds the testcase to confirm that behavior is in the release includes/merged into vitools.

Version 1.0.51- SubstituteWithSNICK fixed

Posted on by

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

Version 1.0.47 – Withstand Bogus Preamble While Parsing Zones

Posted on by

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.