LDAP: couldn't connect to LDAP server

Differences

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

--- releases:7.0.5_20181203 [2019/01/17 16:51] – dshah
+++ maintenance:releases:7.0.5_20181203 [2019/12/23 15:48] (current) – yspeerte
@@ Line 1: / Line 1: @@
+{{indexmenu_n>20181203}}
+===== NetYCE 7.0.5 Build_20181203 =====
+===== Release notes =====
+Date: 2018-12-03
+\\
+<WRAP widths 60% box safety>
+==== Enhancement ====
+</WRAP>
+=== CMDB objects ===
+<WRAP indent>
+In preparation for the all-new 'Basic Command Jobs' currently under development, several
+reserved objects named 'CMDB' have been added to the NetYCE database. These basic command
+jobs will permit the creation of command-jobs for all devices present in the CMDB table.
+These basic jobs have full support for command and config parsing and have limited parameter
+substitution capabilities.
+To support the use of basic templates and relations, the 'CMDB' objects for 'Client-type',
+'Region', 'Client', 'Site', and 'Service_class' have been added. These objects cannot
+be deleted since they are essential for the functioning these basic jobs.
+For environments where these 'CMDB' objects are perceived as undesirable, they can easily
+be hidden by removing the 'CMDB' client-type from the NetYCE user-groups.\\
+**Note:** Hidden from the BUILD -> MAIN only. The Objects are always seen under Operate -> CMDB
+</WRAP>
+=== New Topo check report ===
+<WRAP indent>
+A specialized report has been added to the Operate - Reports menu: 'Topo check'. This allows the
+modeler to report on all topology links where a mismatch exists between the assigned subnets
+at both ends. Depending on the design such a mismatch could be an issue or not.
+The output lists topos with mismatches only and is sorted by Client_type, Hostname, Link-type.
+Per topology link the missing subnet details are listed.
+</WRAP>
+\\
+<WRAP widths 60% box safety>
+==== Change ====
+</WRAP>
+=== Command jobs ===
+<WRAP indent>
+The preparation and execution of command jobs was extensively modified with the 7.0.5
+release. One of these changes involved generating the command job configurations
+at the time of execution instead of job submission time.
+The scenario command '**Cmd_exec**' was modified to generate the commands from the 'template'
+that are the commands entered. It would use this <jobid>.cmd as template to generate the
+commands using the node specified in the '**-n**' option and then execute the result on the
+same device. The '-f' option is used to name generated command file for reference purposes.
+The scenario line would then be similar to this:
+<code>
+-- example
+<node> = NL-ACME-CPE
+Cmd_exec -n <node> -f <node>.cmd <verbose>
+-- generates NL-ACME-CPE.cmd using NL-ACME-CPE data and executes it on NL-ACME-CPE
+</code>
+However, this approach would prevent you from generating the commands from this 'template'
+when the execution must be performed on a different node than the node (or context) these
+commands were generated for. To resolve this issue, the option '**-o**' was added to the
+Cmd_exec. The '-o <node>' (origin-node) specifies the node name whose context is used to
+generate the commands from the command-job 'template'. These commands are then executed
+on the node specified with '-n' as usual.
+When the -o is omitted, the '-n <node>' is providing the context from which the commands
+are generated. The Cmd_exec will NOT generate the named file if it already exists.
+<code>
+-- examples
+<node> = NL-ACME-CPE
+<code_node> = NL-AMS-CR02
+Cmd_exec -o <node> -n NL-AMS-CR01 <verbose>
+-- generates the file NL-ACME-CPE.cmd using NL-ACME-CPE data and executes it on NL-AMS-CR01
+Cmd_exec -o <node> -n <core_node> -f <core_node>.cmd <verbose>
+-- generates the file NL-AMS-CR02.cmd using NL-ACME-CPE data and executes it on NL-AMS-CR02
+</code>
+The change requires the engineer to explicitly define the context and the target nodes
+instead of relying on a command file that was implicitly generated at job-submission time.
+This approach also allows to re-use the command 'template' for multiple nodes within the
+scenario. The context and target nodes can be switched as appropriate.
+<code>
+-- example
+<node> = NL-ACME-CPE
+<code_node1> = NL-AMS-CR01
+<code_node2> = NL-AMS-CR02
+Cmd_exec -o <core_node1> -n <node> -f <node>_part1.cmd <verbose>
+-- generates NL-ACME-CPE_part1.cmd using NL-AMS-CR01 data and executes it on NL-ACME-CPE
+Cmd_exec -o <code_node2> -n <node> -f <node>_part2.cmd <verbose>
+-- generates NL-ACME-CPE_part2.cmd using NL-AMS-CR02 data and executes it on NL-ACME-CPE
+</code>
+</WRAP>
+=== Node port display order ===
+<WRAP indent>
+When viewing the ports of a node, the ports are virualized per slot in groups of ports per
+port-type (e.g. Fast_ethernet, Gigabit-ethernet, Loopback, Port_channel). The order of these
+port-types was often inconvenient since it was more or less random.
+This behaviour is now changed and lists the port-types in a fixed order: Ethernet, Fast_ethernet,
+Gigabit_ethernet, TenGigabit_ethernet, etc. The order is controlled using the internal Port_class
+table where also the port-type name is mapped to the port-class. If required, the order can be
+modified to customer taste.
+</WRAP>
+=== Node port display truncated ===
+<WRAP indent>
+On nodes where the port-ids of a port-type exceed 150 will the clickable ports now be truncated.
+This is most often the case for Loopback or Port_channel type ports, but the behaviour is general.
+It will prevent extensive scrolling past unused port-id's and improves the rendering speed of
+the ports by the browser.
+When the list of ports for a port-type is truncated, it is indicated by a [=>] symbol indicating
+the list continues but is not shown. The full list will be available using the grid at the top of
+the form.
+</WRAP>
+\\
+<WRAP widths 60% box safety>
+==== Fix ====
+</WRAP>
+=== Scenario variable resolving ===
+<WRAP indent>
+With the redesigned command job and scenario handling of version 7.0.5 the variables handling
+was modified. The command generator now has access to all scenario variables which in turn
+extended to the relations.
+With this behaviour in place we believed the scenario would no longer require variable
+substitution from the node. This assumption proved incorrect. Although scenario facilities exist
+to access relations for a node, existing scenarios in production were incompatible.
+As a result the original scenario behaviour has been re-implemented. At time of execution,
+the entire scenario is parsed for variables and relations from the <node> context and substituted.
+This restores the functionality of the existing scenarios.
+</WRAP>
+=== Node_log support ===
+<WRAP indent>
+The Vendor modules were for the 7.0.5 release updated to behave more consistently and allow better
+control over error conditions. This was partly realized by creating more common functions for
+all vendors to use. Most of the existing functions were ported to these new vendor modules, but
+not all. The function to store the results of 'show' commands proved to be amongst these, although
+not intentionally.
+To correct this situation, the function has been re-implemented. CLI commands starting with vendor
+specific key words like 'show' or 'display' are detected and their results stored in the YCE Node_log
+table for later examination or reporting.
+  * the 'show'-type commands must be fully typed, abbreviations are not supported
+  * the 'show'-type commands are executed as any other, only afterwards is the command evaluated as a storable result and saved in the database.
+  * the 'show'-type commands are expected to be executed in the appropriate mode. The vendor module will not magically switch between enabled and disabled modes.
+Most vendors have the commands for 'show' or 'display' and 'ping', 'dir', 'do' recognized.
+</WRAP>
+=== Duplicate node slots ===
+<WRAP indent>
+A bug where romoved nodes did not clean up their node-slots caused duplicate node-slots when these nodes
+were re-created. Altough the problemof not removing the slots was fixed, the existing duplicates
+would not be removed until a port was added or removed from the node.
+A patch will be executed when updating the NetYCE system to remove these duplicate slots.
+</WRAP>
+=== Show command logging ===
+<WRAP indent>
+When executing cli jobs on a device, the job can contain 'show' commands. The results
+of these commands are logged in the job log but were also stored in the NetYCE database
+in the Node_logs table for reporting purposes.
+This functionality was not ported correctly to the various vendor modules when version
+.0.5 was prelim released. However, a bug prevented the actual use of this restored function
+which has now been fixed.
+</WRAP>
+=== Command parsing ===
+<WRAP indent>
+Command parsing in job scenarios fails due to a misconfiguration in the state-machine
+configuration of several vendors. The functionality has now been restored.
+</WRAP>