There was no support yet for file transfers on Junos using a VRF. While implementing this we encountered certain Juniper devices incapable of doing any type of transfer using a VRF.

To deal with these situations, a last-resort method was incorporated to collect the active configuration of a node using screen scraping - reading the configuration from the 'screen' using a display command.

The Stored jobs permissions are revised such that:

• Users in the same group may save/update or delete a stored job
  (the owner will be updated to the user saving)
• Users of a 'higher' permission level may save/update or delete a stored job
  (on save/update the group and owner will not change - unless group or user do no longer exist)
• Users of the same or lower permission level may not update or delete a stored job

Additionally, the Command-job tool was updated to make the 'load' and 'save' functions to become clearer. A 'filter' field was added (supporting substring and wildcards) to narrow the list of stored jobs to load.

Both the 'Command jobs' and 'Basic command jobs' tools have been updated.

Two new customization 'tweak' settings were added to the 'Admin - Lookup'.

• Filter_cmdb_nodes
  CMDB nodes that are assigned a client-type will be included in the node grid. As they at this time cannot be manipulated there, an option to filter these CMDB nodes was desired. Setting this tweak will hide the CMDB nodes from the Man build Node grid.
• Main_substring_search
  The main Build 'Search' function currently has a default mode using wildcards. Setting this tweak changes the non-wildcard searches from a literal match into a substring match. This setting will be enabled by default after the version update.

CentOS 6 was declared end-of-life by CentOS as of November 30th, 2020. NetYCE continued active support of existing installations using CentOS 6 after this date.

Since November 2020 the security and feature gap has kept growing forcing us to to discontinue active support of CentOS 6.x and RedHat 6.x releases per November 30th, 2021.

Our current support concentrates on CentOS 7.x releases and will continue to do so until its formal end-of-life set for June 30th, 2024. CentOS 8 releases are not supported as it was prematurely declared end-of-life per December 31, 2021.

Existing CentOS 6 users are recommended to request a download of the CentOS 7 based NetYCE virtual machine (OVA image) using the Free download form.

Although the CentOS/RedHat 6 support will be discontinued as of November 30th, 2021, some customers may wish to continue to run using these systems for a while longer.

As our latest developments rely on CentOS/RedHat 7, and is supported using our YCEperl-7.2.2 package, the newer NetYCE releases will no function properly in all areas. Especially the REST API's and the forthcoming front-end updates will require an update.

To this end we created YCEperl-7.0.3 that can only be installed on CentOS/RedHat 6.10 systems and supersedes the YCEperl-7.0.2.

Note that CentOS/RedHat 7.x systems must use the YCEperl-7.2.2 support package as it can only be installed in those environments.

A front-end issue was fixed where after selecting a different 'Slot' in the port view of a node, it would display no ports at all for any node accessed thereafter.

When executing a Service-type or task that referenced the currently selected service, the Service-type would fail with an error. A bug caused the value of the used service-key to be incorrect resulting in a failed database lookup. This issue was corrected.

At the NCCM sections, in the polling group edit form, you were unable to set the value of Max retries to 0. This resulted in that every node was rescheduled upon failure at least once, and that it was not possible to disable nodes immediately after a failed connection.

You are now able to set the Max retries value of a polling group to 0, which allows you to immediately disable nodes for the nccm after a failed poll.

When retrieving the configuration backup of a physical Checkpoint device into the NCCM the operation would fail by not locating the backup file. The problem proved to be the location of the backup file on the device that was to be transferred to NetYCE.

By correcting the location references could the issue be resolved. The fix also includes handling a TFTP error message when transfer times out

After the latest NetYCE software upgrade the front-end GUI would behave unresponsive. Analysis demonstrated that the back-end did not consistently reply to front-end requests until the back-end was properly restarted.

Where normally the back-end is restarted using a fast hot-deploy mechanism, this mode of restart was not sufficient following the type of (routing) changes involved with this upgrade. To resolve the issue, a back-end restart following an upgrade will now always use the slower (but thorough) cold restart.

When setting up a NetYCE server to support both IPv4 and IPv4 (dual stack), the API back-end would only respond to IPv6 requests. Users connecting using IPv4 would not be able to login or would fail to receive data from the back-end.

This problem has been corrected.

A few issues have been resolved for the Cisco XE vendor module.

• The variable for the Software version of the Cisco XE device was not set when executing a job on the device
• The scenario command 'file_get' would fail because of insufficient privileges. This was corrected by ensuring the 'enable' mode is reached before attempting to transfer the requested file

Customers noted that the latest upgrade caused their own periodic NetYCE tasks were removed. It proved that the yce_setup tool was generating a default crontab after each execution. Proper detection of an existing crontab and selectively updating it resolved the issue.

The 'Search' option of the Evpn form did not work. No results were found due to an incorrect database query. This has been corrected

With a recent update of the Chrome browser an annoying 'feature' of this browser became apparent in our front-end. Several form fields containing password-like values are involuntarily filled with the user password potentially replacing valid data with unintended values.

By adding specific tags to these form fields, Chrome will no longer try to autocomplete these fields.