Author Archives: Allan Clark

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.

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