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

Version 1.0.47 – Withstand Bogus Preamble While Parsing Zones

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.

Version 1.0.46 – Check for Driver Availability During Build

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.

Version 1.0.41 – Added Detail to Explain FTP Checksum non-Match

FTP Checksum validation was improved in Version 1.0.36; there was a typo, and really very little explanation.

Although there’s not a whole lot more detail, the reason for a Checksum Unknown was described with a hint as to how to use this capability in future.

As a note: the checksum file format intentionally matches the output of the “md5sum” or “md5” command line tools to which other tools are compatible. Most checksum tools are compatible.

Of note: using vict.jar to upload automatically produces checksum files for validation.

For example:

vict.bat -U (server) -u file1 -u file2 -u file3

or:

java -jar vict.jar -U (server) -u file1 -u file2 -u file3

This simple functionality creates a checksum, sends it to the server, uploads the file(s), and confirms checksum with the server (where supported).

The Server-side FTP check functionality that alerts us to uploads automatically uses the checksum file to validate accuracy of the upload.

I cannot see how to make this easier.

Version 1.0.40 – Confirm that Duplicate WWPNs Are Caught

In VirtualWisdom4 release 4.0.2, it was noticed that the JSON Validation before import does not trap duplicate WWPNs. Unfortunately, this was exasperated by one customer who had multiple duplicate entries in their CSV WWPN/alias maps that were previously routinely imported into VW3.

VirtualWisdom4 may still be vulnerable, so the NicknameParser now independently discards duplicate WWPNs; otter parsers currently may not.

This release confirms that the fibrechannel-parsers inbuilt to the vitools-1.0.40 jar file include this fix.

Version 1.0.39 – Confirm 4.0.2-based fcport Entities

in fibrechannel-parsers-0.3-121, the VW4 release 4.0.2 feature of fcport entity import was added. An FCPort acts as either HBA ports or Storage Ports when using Entity Creation Utility to create entities: the selection list for Host includes both HBA Port and fcports, for example.

In order to confirm that we always have a fcparsers version that includes this fix, a check case was added to confirm functionality, or fail if absent.

vitools-1.0.39 should always include this feature in the in-packed parser

Revision 1.0 – ShowZoneParser with Postfixed Aliases

This is the first commit shared from the new build of the vitools project. Users should see no difference except the 1.0 version to mark the newer build method. The third digit of the version is still auto-incremented, and that’s the one that counts.

In this revision, fibrechannel-parsers improved ShowZoneParser ability to parse zone content lacking prefixed fcalias values but with postfixed aliases after WWPNs. To ensure we always pick up a repaired version, vitools adds a test to confirm every release continues to fix this issue.

Revision 677 – Additional Dupe WWPN Issue When Lacking fcalias

Another issue was discovered in that Cisco “show zones” command is giving results such as:

zone name z23_test44 vsan 300
    pwwn 10:00:00:00:c9:12:34:56 [realalias]
    pwwn 10:00:00:00:c9:12:34:57 [otheralias]

Lacking the fcalias, this confused the Show Zone parser (Revision 657 – Cisco Show Zone), in a way slightly different than in Revision 674 – Dupe Alias in Show Zone. There’s no ambiguity between two nicknames or aliases, but the parser wasn’t picking up all possible pawn lines (i.e. reporting 10:00:00:00:c9:12:34:56,realalias but not reporting 10:00:00:00:c9:12:34:57,otheralias.

This was resolved by creating an additional parser with more code paths in the ShowZone2Parser to collect all subparts of a zone into the zone after the section is complete, and to collect all parts into each fcalias as a new fcalias was found or the zone is completed.

There’s still a few caveats to chase down, as noted on that class’s description.

A test case was added to this project to confirm the problem is resolved going forward.

Revision 674 – Dupe Alias in Cisco Show Zones

A problem was discovered in that Cisco “show zones” command is giving results such as:

zone name z23_test44 vsan 300
  fcalias name testhost vsan 300
    pwwn 10:00:00:00:c9:12:34:56 [realalias]

This confused the Show Zone parser (Revision 657 – Cisco Show Zone), plus it was ambiguous which name (“testhost” or “real alias”) should be used.

This was resolved in ShowZoneParser to use “realhost” silently; a test case was added to this project to confirm the problem is resolved going forward.

Revision 672 – OnCommand and DCNM Clients Migrated

In this revision, minor changes were done to move the OnCommand and DCNM client code outside of the non-public source base and into the public source base at OSMURLConnection.java and DCNMURLConnection.java. This allows for external audit of the code and may improve trust and reduce concern. This is very similar to the work done in Revision 670 – BNA Client Migrated

As with Revision 670, 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 DCNM backend-database client remains beta-quality and requires further testing if a user is willing; the OnCommand client has been heavily tested.

The OSM or OCI backend-database client was added 14 months ago (Revision 516 – Added parsing of OnCommand Data for Nicknames); DCNM backend-database client was added 13 months ago Revision 541 – Added parsing of DCNM Data for Nicknames). The OnCommand client was altered to append a fabric name for a specific environment 11 months ago (Revision 578 – NetApp msosmsql Pseudo-Protocol Adds Fabric Suffix) but can be used to show how easily the output can be transformed.