Revision 615 – RemoveNicknames Allows Nickname-Diff Creation

There has been a strange issue with diminishing efficiency of nickname import as the number of nicknames increases and the number of other threads competing for a database lock increases. Apparently it’s too difficult check nicknames before setting, and I’ve seen roughly 3 nicknames every 2 seconds on some portals.

Considering this, and that we have ways of getting nicknames from files (including basic 2-column format), I’ve added a method of taking a parsed list of nicknames and removing it from the nickname base.

The “–removenicknames=” option (“-R”) parses a nickname input (BNA, file://, OCI, HTTP, FTP, same logic as adding) and removes them from the internal nickname base rather than adding.

This would let us:

  1. collect new nicknames from all the current sources
  2. remove a list of assumed-current nicknames
  3. write out the remainder for import

Additionally, collecting the current assumed-current plus the new nicknames gives us the new assumed-current.

Revision 613 – fctransfers Gives us SFTP Uploads

In rev 605, the code for uploads was completely dependent on the code brought in with fctransfer.jar’s convenience library.

This revision evolves that change: all uploads are delegated to the fctransfer project, which means we get SFTP uploads for free:

Upload methods are now:

  • FTP: java -jar vict.jar -U ftp://scott:tiger@ftp.example.com/path/ -u file1 -u file2
  • SFTP: java -jar vict.jar -U sftp://scott:tiger@ftp.example.com/path/ -u file1 -u file2

Notice the similarity? That’s intentional.

Of course, both upload methods send a checksum including a notify element.

There remains some oddity in the commons-net-ssh used; I may need to swap out the underlying ssh to sshj or such.

Revision 609 – Helpful Documentation around DNS and Certificate-protocol Convenience

In this revision, a few whitespace and documentation changes were made:

  • If DNS was configured but filtered/firewalled, the messages would be difficult to understand. Immediate reaction/retry suggestions are added to the error text
  • If the user tried the -C/–vcentercert option but didn’t give a protocol, the tool would prepend it. The error message said “You have an error, trying with a protocol” but that was misunderstood as “you have an error. the sky has fallen, nothing further will be done”. The error message is augmented to be a bit more understandable.

Revision 602 – Split and Build with external Parsers, Solved a Parse issue

In this revision, the parsing code is now external; it has been split out to “fcparsers.jar” from fcparsers-java rpm visible at github.com/chickenandpork/fibrechannel-parsers/ … this was done to improve code visibility and to allow bug reports to be created more closely to the specific piece of code involved.

In doing so, I also chased down a parsing issue in that the following block would produce a nickname short:

alias: NASMany_654321
                10:00:00:00:c9:44:44:10; 10:00:00:00:c9:44:44:11
                10:00:00:00:c9:44:44:20; 10:00:00:00:c9:44:44:21
                10:00:00:00:c9:44:44:30; 10:00:00:00:c9:44:44:31

Results:

10:00:00:00:c9:44:44:11,"NASMany_654321"
10:00:00:00:c9:44:44:20,"NASMany_654321"
10:00:00:00:c9:44:44:21,"NASMany_654321"
10:00:00:00:c9:44:44:30,"NASMany_654321"
10:00:00:00:c9:44:44:31,"NASMany_654321"

… clearly missing “10:00:00:00:c9:44:44:10” (and yes, per the weak consuming parser to which we send this result, no space can be between the WWN and the alias).

That was resolved by fixing the byacc parser code. All six members now show up.

Revision 600 – (weak) Suggested Nicknames for Apparent NetApp WWN Patterns

Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 500a098300004060 shows “NetApp-4060-iGrp0-0N” giving suggested nicknames to NetApp Devices.

Just like Apparent VPLEX Patterns, this WWN Descriptor is empirically-based. Additional WWPN samples would help guide a better, more precise solution.

Revision 599 – (weak) Suggested Nicknames for Apparent VPLEX WWN Patterns

Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 50001442607a3b00 shows “VPlex-07a3b-A0-FC00” giving suggested nicknames to EMC VPLEX devices similar to the output of the CLI command ls -l /engine/**/ports.

This WWN Descriptor is not very precise, but is empirically-based. Additional WWPN samples would help guide a better, more precise solution.

Revision 597 – Zone-Voting Accepts Dupes by Default

Based on some work I was doing with JP “Skwerl” C, I found/remembered/was-embarassed-by Zone-voting ignoring possibilities of duplicate aliases as a default behavior.

This might have been cool before, but it’s out of fashion now. In fact, I find so many customers duping their nicknames, I wonder if there’s some advice on the ‘net suggesting it’s a good practice. Understandably, these are labels being extracted from zone names, so I cannot claim to be the ivory tower of accuracy or best-practice.

Inspection-worthy units have a more difficult time passing combat.

In this revision, I converted ZoneVote to default to allowing dupes; highlights some mismatched assumptions in test cases. see also “Zone Vote is only an approximation” 🙂

Revision 592 – CSVPipe Separated

Much as I don’t like CSV, I’ve used arrays of strings just as some would use CSVs. If only CSVs were deterministically-parsed… if only spaces didn’t confuse some parsers…

… so in support of butchering text-streams with CSV-like data, and to facilitate the post-processing of content (ie feel like a min/max/avg/deviation/mean+/- 3sigma?), I’ve separated off the RowPrinter content into a separate jar. This allows a basic file to be read, parsers, munged, and ejected back out for others to consume.

A few testcases help to keep me honest.

Tersely, I wrote in the change log:CSVPipe: different chunking and summarizing; ability to set diff keys for chunking; test cases; testsuite.at

Revision 590 – Added –UploadNotify as a Checksum Comment

In order to allow upstream notification, I’ve added the “–uploadnotify” argument to the FTP uploader:

VICT.BAT -U ftp://scott:tiger@ftp.oracle.com/ --uploadnotify allanc@oracle.com -u logfile1 -u logfile2

Foe each upload, a .sum file would still be generated — in this case, upload1.sum and upload2.sum. The comment “# NOTIFY allanc@oracle.com” is added to the checksum file so that any post-processor knows whom to alert of an upload. If this comment is present and understood, it can be considered advisement, not a directive; default processing may very well occur.

This is not governed by any spec, and I did not find a RFC or other open spec suggesting a format. I’ve suggested using an RFC1738-compatible URL. The format of the checksum file remains compatible with the “sum” and “md5” commands.