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.

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.

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

Posted on by

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

Posted on by

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

Posted on by

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

1.0.36 – Expand Entity Exclusion; ftp checksum improved

Posted on by

Parsing the error log from an Entity Validation now removes the MODIFY failures as well. Additionally, the FTP post-upload checker looks for a checksum file, and if so, checks the checksum against that file to more immediately informs of failed uploads.

The underlying library fibrechannel-parsers improved the ability to remove duplicate entities: entities that exist with a requirement to MODIFY are interpreted, and removed post-pattern-aggregation from the internal tree which generates the JSON result. This version confirms that behavior is present and remains functional.

This was partially done by removing duplicate code: the use of FCParser rather than the similar code which formed the basis of FCParser allowed those changes to overtake and offer the improved VW4InvalidAddedParser and the ShowZone2Parser.

Finally, slight modifications were done on the FTP upload checker: any detected .sum file is ignored in the short-term, but if a file is uploaded and a .sum file exists, the checksum is compared to the generated/detected checksum, and matches/mismatches are reported in the subject of the outgoing warning email:

Subject: Checksum:OK New File Upload 2014-07-27 21:10:00

This is intended to allow mailbox sorting to accelerate attention to the issue and fail-fast the upload.

Revision 1.0 – ShowZoneParser with Postfixed Aliases

Posted on by

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

Posted on by

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

Posted on by

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.