maintenance:releases:7.2.0_20210708
Differences
This shows you the differences between two versions of the page.
| maintenance:releases:7.2.0_20210708 [2021/07/08 14:37] – created yspeerte | maintenance:releases:7.2.0_20210708 [2024/07/03 12:31] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | {{indexmenu_n> | ||
| + | |||
| + | ====== NetYCE 7.2.0 Build_20210708 ====== | ||
| + | ====== Release notes ====== | ||
| + | Date: 2021-07-08 | ||
| + | |||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Enhancement ===== | ||
| + | </ | ||
| + | |||
| + | ==== VRF support for Junos filetransfers and screen scrape fallback ==== | ||
| + | <WRAP indent> | ||
| + | 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 ' | ||
| + | using a display command. | ||
| + | </ | ||
| + | |||
| + | ==== Stored-job permissions ==== | ||
| + | <WRAP indent> | ||
| + | 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 ' | ||
| + | * Users of the same or lower permission level may **not** update or delete a stored job | ||
| + | |||
| + | Additionally, | ||
| + | |||
| + | Both the ' | ||
| + | </ | ||
| + | |||
| + | ==== Main ' | ||
| + | <WRAP indent> | ||
| + | Two new customization ' | ||
| + | |||
| + | * '' | ||
| + | * '' | ||
| + | </ | ||
| + | |||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Change ===== | ||
| + | </ | ||
| + | |||
| + | ==== CentOS 6.x support ==== | ||
| + | <WRAP indent> | ||
| + | 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. | ||
| + | </ | ||
| + | |||
| + | ==== CentOS-6 YCEperl update ==== | ||
| + | <WRAP indent> | ||
| + | Although the CentOS/ | ||
| + | customers may wish to continue to run using these systems for a while longer. | ||
| + | |||
| + | As our latest developments rely on CentOS/ | ||
| + | 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/ | ||
| + | and supersedes the YCEperl-7.0.2. | ||
| + | |||
| + | Note that CentOS/ | ||
| + | only be installed in those environments. | ||
| + | </ | ||
| + | |||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Fix ===== | ||
| + | </ | ||
| + | |||
| + | ==== Node slot tab failure | ||
| + | <WRAP indent> | ||
| + | A front-end issue was fixed where after selecting a different ' | ||
| + | a node, it would display no ports at all for any node accessed thereafter. | ||
| + | </ | ||
| + | |||
| + | ==== Service-type failure | ||
| + | <WRAP indent> | ||
| + | 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. | ||
| + | </ | ||
| + | |||
| + | ==== NCCM Polling Max Retries ==== | ||
| + | <WRAP indent> | ||
| + | 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. | ||
| + | </ | ||
| + | |||
| + | ==== Checkpoint backup ==== | ||
| + | <WRAP indent> | ||
| + | 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 | ||
| + | </ | ||
| + | |||
| + | ==== GUI failure after upgrade ==== | ||
| + | <WRAP indent> | ||
| + | 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. | ||
| + | </ | ||
| + | |||
| + | ==== Dual stack backend ==== | ||
| + | <WRAP indent> | ||
| + | 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. | ||
| + | </ | ||
| + | |||
| + | ==== Cisco XE fixes ==== | ||
| + | <WRAP indent> | ||
| + | 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 ' | ||
| + | </ | ||
| + | |||
| + | ==== Crontab entries ==== | ||
| + | <WRAP indent> | ||
| + | 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. | ||
| + | </ | ||
| + | |||
| + | ==== Evpn Core search ==== | ||
| + | <WRAP indent> | ||
| + | The ' | ||
| + | </ | ||
| + | |||
| + | ==== Chrome Autocompleting ==== | ||
| + | <WRAP indent> | ||
| + | With a recent update of the Chrome browser an annoying ' | ||
| + | |||
| + | By adding specific tags to these form fields, Chrome will no longer try to autocomplete these fields. | ||
| + | </ | ||
| + | |||