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). | ||
+ | </ | ||
+ | |||