Differences

This shows you the differences between two versions of the page.

--- maintenance:releases:7.1.1_20190522 [2019/07/16 13:15] – ↷ Page moved from releases:7.1.1_20190522 to maintenance:releases:7.1.1_20190522 jbosch
+++ maintenance:releases:7.1.1_20190522 [2024/07/03 12:31] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+{{indexmenu_n>20190522}}
+===== NetYCE 7.1.1 Build_20190522 =====
+===== Release notes =====
+Date: 2019-05-22
+> Note: These release notes form an addendum on the release notes that accompanied the initial build of version 7.1.1. Please consult the (extensive) 7.1.1 [[maintenance:releases:7.1.1_20190501|NetYCE 7.1.1 Build_20190501]] build notes when updating from a 7.0.5 or older version.
+\\
+<WRAP widths 60% box safety>
+==== Enhancement ====
+</WRAP>
+=== Service IP search ===
+<WRAP indent>
+Some modeled services can have many ip-subnets assigned to it. To simplify managing these the
+'search' option familiar for many other data grids has been added to the Service Components
+tabs for IPv4 and IPv6.
+</WRAP>
+\\
+<WRAP widths 60% box safety>
+==== Change ====
+</WRAP>
+=== Scenario parameters ===
+<WRAP indent>
+The [parameters] section can be used to assign (static) parameters to be used in the command
+section of the Command Jobs, but also in the templates and relations. These parameters can
+be assigned string and numbers, but also use variables of the node and even its relations.
+<code>
+[parameters]
+my_var1 = 'some string'
+my_var2 = <some_variable>
+my_var3 = <variable@relation:value>
+my_var4 = <variable@relation:column=value>
+</code>
+All these assignemts worked as expected, save the last one. The 'my_var4' value would not be resolved and
+produced an incomplete string of the original. This issue has been resolved.
+Another issue that was resolved involved indirect assignments: Scenario parameters based on other
+scenario parameters. These were substituted correctly when using strings as in 'my_var5', but not
+for 'my_var6'. These indirect resovles are now functional as well.
+<code>
+[parameters]
+my_var1 = 'some string'
+my_var4 = <variable@relation:column=value>
+my_var5 = <my_var1>
+my_var6 = <my_var2>
+</code>
+</WRAP>
+\\
+<WRAP widths 60% box safety>
+==== Fix ====
+</WRAP>
+=== Test Command parsing ===
+<WRAP indent>
+The command-parse tool has been reworked for a cleaner and more intuitive layout.
+Selecting a template no longer changes the filters allowing for a more trial-and-error approach.
+The tool now supports multivendor parsing templates for all client-types. The parsed
+results are shown separate from the debugging output to better find and interpret the
+results. When results are lacking it is indicated.
+Command parsing templates without a 'production' revision are not included in the list of templates.
+</WRAP>
+=== Configuration generator ===
+<WRAP indent>
+An situation was encountered where a job would not finish and consume a full 100% of a CPU.
+This proved to be caused by the configuration generator where the variable resolving ended up
+in a infinite loop.
+A parameter in the scenario was assigned value that was pointing to itself: "var_name = <var_name>".
+The generator was modified to detect these looped references at several syntaxes and produce
+appropriate "Circular reference" errors.
+</WRAP>
+=== Config_create append ===
+<WRAP indent>
+The scenario command ''Config_create'' has an option, ''-x'', to cause it to append the parsed
+template output to an existing command file. It was found that this behaviour was also present
+without the -x.
+This was corrected.
+</WRAP>
+=== Ldap login ===
+<WRAP indent>
+A problem was encountered when Ldap authentication failed due to group assignment validation.
+Depending on the schema deployed this issue could not manifest itself, or only under some
+circumstances.
+The fix involved extracting the 'DN' from the Ldap group record in the proper way.
+</WRAP>