maintenance:releases:8.0.0_20220516
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| maintenance:releases:8.0.0_20220516 [2022/05/17 15:34] – created yspeerte | maintenance:releases:8.0.0_20220516 [2024/07/03 12:31] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | {{indexmenu_n> | ||
| + | |||
| + | ====== NetYCE 8.0.0 Build 20220516 ====== | ||
| + | ====== Release notes ====== | ||
| + | Date: 2022-05-16 | ||
| + | |||
| + | > <color orange> | ||
| + | NOTICE \\ | ||
| + | This set of release notes reflects the work in progress. Each of these | ||
| + | items will become available with the next release and will be made available | ||
| + | in the [[maintenance: | ||
| + | </ | ||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Featured ===== | ||
| + | </ | ||
| + | |||
| + | ==== TMF941 API version2 ==== | ||
| + | <WRAP indent> | ||
| + | This pre-releases the TMF641 API version2 that supports | ||
| + | one ServiceOrder. The implementation of the new ServiceOrder required a different | ||
| + | set of NMS tables to support the per-ServiceItem states and their effect on the | ||
| + | ServiceOrder state. | ||
| + | |||
| + | Version 2 is superseding version 1 but is not replacing it. Both will be available | ||
| + | side by side for some time before it is obsoleted. Note that no history is carried over | ||
| + | from version 1 to version 2. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== OS Repository ==== | ||
| + | <WRAP indent> | ||
| + | A new Operating System file repository was added to NetYCE to manage the numerous | ||
| + | image files of the different vendors and hardware-models of your networking devices. | ||
| + | |||
| + | The repository consists of two parts. First of all the disk-space where the files | ||
| + | are stored and monitored is part of the file-transfer directory tree of the application | ||
| + | which allows all your devices access using all common protocols (scp, sftp, ftp, tftp). | ||
| + | This disk space can be shared using Network File System (NFS) among all NetYCE servers | ||
| + | or any Unix based server to act as a distributed disk-share without duplication of files. | ||
| + | Active monitoring of all file activity (adding, updating, moving, deleting) will | ||
| + | automatically adjust the OS repository to reflect these changes. | ||
| + | |||
| + | Secondly, the user front-end form, which can be found under ' | ||
| + | allows the user to organize the image files into file-sets associated with a Vendor and | ||
| + | a Device type. Each file-set created is intended to assist the user in finding or | ||
| + | selecting the image files needed to a specific device-type and OS version or feature | ||
| + | set. As image files can be used for many device-types, | ||
| + | shared usage and status. | ||
| + | |||
| + | Finally, a couple of Scenario commands were added to locate image files in the repository | ||
| + | for use in OS upgrade scenarios. These commands will also allow access to the meta-data | ||
| + | of each file-set to simplify copy and activation actions. | ||
| + | |||
| + | </ | ||
| + | |||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Enhancement ===== | ||
| + | </ | ||
| + | |||
| + | ==== Template markers ==== | ||
| + | <WRAP indent> | ||
| + | We added support for the variables < | ||
| + | |||
| + | However, a few shortcomings with this approach were observed: first, all templates will need modification - an unpleasant task. Second, when a sub-template is done, config generation returns to its parent to process the remaining lines of that template. It is often hard to locate which template that was, especially when a deeper template tree was used. | ||
| + | |||
| + | To resolve these issues, an automatic ' | ||
| + | |||
| + | This feature is controlled by the " | ||
| + | |||
| + | When the templates are used hierarchical, | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Re-schedule jobs ==== | ||
| + | <WRAP indent> | ||
| + | The new Re-schedule job option is available from the 'Job logs' pop-up window. It is accessed from the Job-logs and the Scheduled-jobs forms. | ||
| + | |||
| + | In order to re-schedule a job the job ' | ||
| + | By default this period is 30 days and can be modified using the " | ||
| + | |||
| + | Another requirement is that the job **must** have been executed, or at least be running. | ||
| + | |||
| + | If these conditions are not met, the Re-schedule button will not be available. | ||
| + | |||
| + | The implementation allows for EDITING the job " | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Legal message ==== | ||
| + | <WRAP indent> | ||
| + | Customers can now format a legal or other customized message on at the login page. | ||
| + | To configure, access the ' | ||
| + | category. Find the variable ' | ||
| + | to 1 to display the message in the description field. The message can be formatted using html | ||
| + | tags and is displayed centered below the login box. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Compliancy ' | ||
| + | <WRAP indent> | ||
| + | The Compliance Policies form now has a ' | ||
| + | It creates a copy of the selected rule for further editing. | ||
| + | </ | ||
| + | |||
| + | ==== Emailing Custom reports ==== | ||
| + | <WRAP indent> | ||
| + | The ' | ||
| + | to be emailed to one or more addresses when the scheduled report is completed. | ||
| + | |||
| + | The resulting CSV report will be included in the message body and as an attached csv-file. | ||
| + | To limit the number of lines in the message body, the Settings Tweak ' | ||
| + | be modified from its default of 500 lines. | ||
| + | </ | ||
| + | |||
| + | ==== Backup Search ==== | ||
| + | <WRAP indent> | ||
| + | The ' | ||
| + | |||
| + | These filters have been extended to allow selections using ' | ||
| + | </ | ||
| + | |||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Change ===== | ||
| + | </ | ||
| + | |||
| + | ==== Hostname restrictions ==== | ||
| + | <WRAP indent> | ||
| + | As per RFC-952 the hostname restrictions have been relaxed to allow leading numbers too. | ||
| + | Hostnames were previously enforced to start with a letter, rejecting leading numbers and | ||
| + | other characters. | ||
| + | |||
| + | The updated validation still rejects hostnames with leading dashes ('' | ||
| + | </ | ||
| + | |||
| + | ==== Config transfer fallback ==== | ||
| + | <WRAP indent> | ||
| + | Retrieving a backup of a device configuration uses one of four file-transfer protocols, depending | ||
| + | on the device capabilities and preference. Due to a wide variety of dependencies like firewalls, | ||
| + | management vrf, permissions, | ||
| + | reliably. | ||
| + | |||
| + | To circumvent these issues, all our Vendor modules will now fall back to CLI configuration | ||
| + | ' | ||
| + | device by listing it on the display. Although not the most efficient method, but it will allow | ||
| + | for the collection of backup configurations and validation of compliance rules. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Syslog patterns ==== | ||
| + | <WRAP indent> | ||
| + | Additional Syslog patterns have been added to the NCCM configuration file. These patterns | ||
| + | are vendor specific and are used to detect a configuration change. The system will then | ||
| + | setup a session to the device to retrieve the latest configuration and store it in the NCCM. | ||
| + | A subsequent compliance check is also automatic. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Configuration censoring ==== | ||
| + | <WRAP indent> | ||
| + | When reviewing the configurations in the NCCM tool ' | ||
| + | configuration differences (or fill config) are displayed using censoring where | ||
| + | passwords are hidden from view. Only higher level users are allowed to view the | ||
| + | configuration uncensored. | ||
| + | |||
| + | On request of customers we lowered the required permission level to ' | ||
| + | view uncensored configurations. We also changed the default to uncensored if the | ||
| + | user permissions allow. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Manager group permissions ==== | ||
| + | <WRAP indent> | ||
| + | The roles and permissions of System users and Manager users have been | ||
| + | somewhat ambigious. The result was an implementation where a Manager | ||
| + | user could change the permissions of his own group. As this is obviously | ||
| + | contra productive, these roles have been redefined. | ||
| + | |||
| + | The permissions of a Manager user have changed. A System user can assign | ||
| + | the client-types and permissions to a Manager group. A Manager user of | ||
| + | that group cannot change its own client-types or its permissions. | ||
| + | |||
| + | That same Manager user **can** change the permissions of other groups, | ||
| + | but only if he has manager permissions of that client type himself. | ||
| + | |||
| + | So effectively the System role determines the permissions of the Manager | ||
| + | role. The Manager role can delegate permissions to other groups. | ||
| + | The System role will have no permission retrictions. | ||
| + | </ | ||
| + | |||
| + | |||
| + | \\ | ||
| + | <WRAP widths 60% box safety> | ||
| + | ===== Fix ===== | ||
| + | </ | ||
| + | |||
| + | ==== Node-groups by SiteCode ==== | ||
| + | <WRAP indent> | ||
| + | It turns out that rules (either include or exclude) on SiteCode work for some Node-groups, | ||
| + | |||
| + | Node-groups on the ' | ||
| + | |||
| + | There are different sql's and mappings for each of these scopes to match YCE and CMDB node attributes. One sql typo error was found for the YCE nodes in the ' | ||
| + | |||
| + | The fix is available in version 8.0.0 as of build 20211230 | ||
| + | </ | ||
| + | |||
| + | ==== Obsolete nodes in NCCM ==== | ||
| + | <WRAP indent> | ||
| + | On occasion, some obsoleted nodes could still be listed in the NCCM for configuration | ||
| + | retrieval. We fixed the situations where this could occur. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== NCCM Vendor filter ==== | ||
| + | <WRAP indent> | ||
| + | We fixed the Vendor_type filter in the NCCM polling status grid | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Scenario parsing ==== | ||
| + | <WRAP indent> | ||
| + | Jobs that are submitted using a scenario that contained parsing errors resulted | ||
| + | in an aborted job as expected, but without any indication of the problem in the | ||
| + | job logs. | ||
| + | |||
| + | This issue has been corrected. Now the job logs will show the parsed scenario including | ||
| + | line numbers and an error message indicating the failing line. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== System alerts ==== | ||
| + | <WRAP indent> | ||
| + | Dismissed system alerts no longer re-appear spontaneously | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Command parsing ==== | ||
| + | <WRAP indent> | ||
| + | Command parsing header recognition improved | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Genesis setup ==== | ||
| + | <WRAP indent> | ||
| + | Some users failed to properly setup the NetYCE downloadable trial VM. | ||
| + | Analysis showed that a specific sequence of actions and prompt answers | ||
| + | resulted in a system that would not allow users to login due to a | ||
| + | non-operational (morbo) backend. | ||
| + | |||
| + | Although the issue could be corrected by following the prompts more | ||
| + | carefully, we implemented precautions against the this and similar | ||
| + | setup situations. | ||
| + | |||
| + | </ | ||
| + | |||
| + | ==== Security fix ==== | ||
| + | <WRAP indent> | ||
| + | A potential security risk was resolved involving downloading NetYCE generated files. | ||
| + | Downloading a file now requires an active session and is restricted to the NetYCE | ||
| + | generated directory-trees. | ||
| + | |||
| + | The login restriction is does not apply to two specific directories: | ||
| + | * / | ||
| + | * / | ||
| + | </ | ||
| + | |||
| + | ==== Repication broken after sw update ==== | ||
| + | <WRAP indent> | ||
| + | A customer reported a problem with a broken database replication after a NetYCE software update. | ||
| + | This customer investigated the issue and also provided us with the required resolution. | ||
| + | |||
| + | This fixed the incorrect database-replication removal on the primary database-server when the | ||
| + | software update was executed on a satellite NetYCE server (a server not running a database). | ||
| + | </ | ||
| + | |||