maintenance:releases:7.1.1_20191219
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | |||
maintenance:releases:7.1.1_20191219 [2019/12/23 15:42] – yspeerte | maintenance:releases:7.1.1_20191219 [2024/07/03 12:31] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | {{indexmenu_n> | ||
+ | |||
+ | ===== NetYCE 7.1.1 Build_20191219 ===== | ||
+ | ===== Release notes ===== | ||
+ | Date: 2019-12-19 | ||
+ | |||
+ | |||
+ | \\ | ||
+ | <WRAP widths 60% box safety> | ||
+ | ==== Enhancement ==== | ||
+ | </ | ||
+ | |||
+ | === Device model and s/w version === | ||
+ | <WRAP indent> | ||
+ | Although NetYCE allows to model a device software-version and hardware type, it did not track | ||
+ | the actually running software-version and hardware-model of each device. To support creating | ||
+ | templates and compliance rules for specific hardware or s/w versions these values are now | ||
+ | dynamically determined at each job start and stored in the NetYCE database. This is done for | ||
+ | both YCE and CMDB based nodes. | ||
+ | |||
+ | These new variables are named < | ||
+ | </ | ||
+ | |||
+ | === Scenario ' | ||
+ | <WRAP indent> | ||
+ | The ' | ||
+ | split into a variable array using a separator character or string. The function accepts multiple | ||
+ | input variables or lists of which each element will be split using the specified separator. | ||
+ | A single list variable will be returned. | ||
+ | |||
+ | The separator may be a single character, a string using wildcards, or a regex pattern. Optional | ||
+ | arguments allow the result to be sorted alphabetically or to return only a limited number of | ||
+ | elements. | ||
+ | </ | ||
+ | |||
+ | === Scheduler node-locks === | ||
+ | <WRAP indent> | ||
+ | The NetYCE job scheduler always accepted jobs for any node and executed the jobs at their assigned | ||
+ | time-slot. When two jobs are scheduled for the same node and their execution overlapped, the resulting | ||
+ | configuration could become unpredictable and might require longer execution times. | ||
+ | |||
+ | To alleviate these complications, | ||
+ | prevent the scheduler to execute more than one job at the time for the same node. Jobs slotted to start | ||
+ | executing while a NetYCE jobs is still running for that node will be put on hold until the previous | ||
+ | jobs finishes. Jobs on hold will have a scheduler state ' | ||
+ | |||
+ | The node for which the lock is checked is the node selected when submitting the job. The locks do not | ||
+ | apply to other nodes the job may open sessions with. | ||
+ | |||
+ | To prevent locking out subsequent jobs because of a very slow job, the maximum duration a node may obtain | ||
+ | an exclusive lock is 10 minutes. After this time a waiting job may start regardless of the still running | ||
+ | job. This second job may also keep the lock for only 10 minutes. | ||
+ | |||
+ | Should a series of jobs all wait for its predecessors to finish, they can only do so for one hour. After | ||
+ | one hour in the ' | ||
+ | is now expired. Suspended jobs can be rescheduled by the operator. | ||
+ | |||
+ | Finally, if the new job-locking by node is undesired, it can be disabled by setting the Lookup Tweak | ||
+ | ' | ||
+ | </ | ||
+ | |||
+ | === SSL hardening === | ||
+ | <WRAP indent> | ||
+ | The NetYCE front-end can be set-up to use the unencrypted ' | ||
+ | https, a SSL-certificate must be created and installed. To further strengthen the security offered by | ||
+ | https and the certificate, | ||
+ | |||
+ | By default NetYCE accepts TLS1, TLS1.1 and TLS1.2. An additional setting in ' | ||
+ | administrator to restrict these protocols to TLS1.2 only. The lower levels are considered weak and | ||
+ | the preferred level is TLS1.2 which all modern Browsers support. Only older revisions or obscure browsers | ||
+ | might not support this level. | ||
+ | |||
+ | By executing the '' | ||
+ | the ' | ||
+ | for TLS1, 1.1 and 1.2. The older SSL2 and SSL3 levels will always be disabled. | ||
+ | |||
+ | < | ||
+ | YCE server roles: | ||
+ | # Hostname | ||
+ | * 0) yce-one | ||
+ | Select the server# to change, ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | enter ' | ||
+ | ' | ||
+ | </ | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Single-sign-on === | ||
+ | <WRAP indent> | ||
+ | NetYCE servers support Single-sign-on (SSO) where the user can login on one NetYCE server and | ||
+ | have login-free access to the other NetYCE servers. This SSO function worked as intended, but | ||
+ | still was cause for confusion when ' | ||
+ | deny access to a tool due to ' | ||
+ | |||
+ | The underlying cause was that customers use various NetYCE environments for ' | ||
+ | Each of these environments can consist of various servers but each has its own (replicating) database. | ||
+ | A user logged-in to one environment can access a server in the other environment and finds that the | ||
+ | session works - up to a point. This was caused by the fact that the user and his credentials exist in | ||
+ | both environments, | ||
+ | |||
+ | The SSO function has now been redesigned to permit access across environments. The session-id does | ||
+ | not have to be present in the ' | ||
+ | exists in both environments and use the same password. If the users' permissions differ across | ||
+ | the environments, | ||
+ | </ | ||
+ | |||
+ | === Reports === | ||
+ | <WRAP indent> | ||
+ | NetYCE offers custom reports using SQL queries on the various databases it manages. These | ||
+ | reports of old were executed on the NetYCE server the user defined them on. Also the resulting | ||
+ | reports were stored on the local disk of the server. Consequently the reports could only be | ||
+ | viewed and retrieved on the same server. | ||
+ | |||
+ | When several servers are deployed the user is often aware where the report is available. However | ||
+ | that is often not the case when the report is to be executed and/or retrieved using the API. | ||
+ | |||
+ | To allow transparent access to report definitions and the generated reports using the both the | ||
+ | front-end and the API, the reporting back-end has been reworked to use the NetYCE database as the | ||
+ | shared environment. Reports can now be created, edited and viewed from any NetYCE server and | ||
+ | the API will execute the reporting from any server. | ||
+ | |||
+ | Generated reports can also be retrieved by URL directly from the browser. The URL uses the format | ||
+ | '' | ||
+ | but can be converted to Dos using '' | ||
+ | |||
+ | The scheduled execution of the reports is balanced (by number of reports) over the available | ||
+ | servers and still uses the standard Unix ' | ||
+ | </ | ||
+ | |||
+ | === Ping tool === | ||
+ | <WRAP indent> | ||
+ | A new ' | ||
+ | nodes fully modeled in NetYCE could be pinged, it can now ping modeled NetYCE nodes, CMDB nodes and | ||
+ | ad-hoc devices using IPv4 and IPv6. | ||
+ | |||
+ | Ad-hoc devices can be entered using a fqdn or an IPv4/IPv6 address. The tool will ping all | ||
+ | (resolved) ip-address three times reporting the resulting round-trip times in ms, or as a | ||
+ | red ' | ||
+ | </ | ||
+ | |||
+ | === CMDB Management VRF === | ||
+ | <WRAP indent> | ||
+ | NetYCE transfers files between its servers and the Network devices by initiating the session | ||
+ | from the devices. More and more designs (and vendors) require that these connections use the | ||
+ | designated Management VRF and for properly modeled YCE nodes this VRF selection works | ||
+ | automatically. | ||
+ | |||
+ | However for CMDB nodes where the available information on each device is severely limited, there | ||
+ | was no option to select the proper Management VRF. To support these configurations the Cmdb_nodes | ||
+ | now have an additional attribute to configure the ' | ||
+ | is empty signifying no management VRF is used. When a value for mgmt_vrf_name is inserted, | ||
+ | it is used for specifying the VRF name for the transfer. | ||
+ | |||
+ | If a node name exists as both an YCE and and as a CMDB node, the YCE node configuration takes | ||
+ | precedence. The Mgmt_vrf_name is strictly used for CMDB nodes. Basic command jobs for ad-hoc | ||
+ | devices that have neither an YCE model nor a CMDB record cannot use a VRF. | ||
+ | </ | ||
+ | |||
+ | === Scenario csv-file/ | ||
+ | <WRAP indent> | ||
+ | Two reporting commands were added to the scenarios: '' | ||
+ | The csv_report can create a custom report output file from variable lists created | ||
+ | in the scenario. A report is created from a single or a number of variables that | ||
+ | have values that are related by row. | ||
+ | |||
+ | The first value of each supplied variable is combined into a row and converted into | ||
+ | a csv (comma-separated-values) line. By doing the same over all items in the lists a | ||
+ | report is generated. The ' | ||
+ | they can be viewed and downloaded using the GUI, or fetched using the API or URL. | ||
+ | |||
+ | The ' | ||
+ | directory. It is then viewable and downloadable from the job details window. | ||
+ | |||
+ | To put this csv-file to additional use: the '' | ||
+ | extended with the '' | ||
+ | log or data file and mail it to his desk, right from the scenario! | ||
+ | </ | ||
+ | |||
+ | |||
+ | \\ | ||
+ | <WRAP widths 60% box safety> | ||
+ | ==== Change ==== | ||
+ | </ | ||
+ | |||
+ | === backslash ' | ||
+ | <WRAP indent> | ||
+ | When using templates and scenario' | ||
+ | indicate a conditional configuration line (using '' | ||
+ | And in scenarios to indicate a special operator (like \s\d\r\n) in regex conditions (e.g. ''/ | ||
+ | |||
+ | To prevent these characters form being interpreted as a template operator and just type the character, | ||
+ | backslash-protection is used. The string '' | ||
+ | refers just to the string and will output '' | ||
+ | |||
+ | However, using this protection in scenarios would lead to unexpected results, often resulting in multiple | ||
+ | levels of protection. The regex example above would work only when stored as ''/ | ||
+ | |||
+ | This less-than-desirable behavior has been addressed in such a way that only a single backslash-protection | ||
+ | is all that is needed. The regex in a scenario is typed as intended without additional backslashes and | ||
+ | to use a literal character in a template or scenario only requires a single backslash. The special characters | ||
+ | like '' | ||
+ | |||
+ | > **Important**: | ||
+ | </ | ||
+ | |||
+ | === SSH-config === | ||
+ | <WRAP indent> | ||
+ | Most communication with the devices nowadays use the SSH protocol. This protocol evolved | ||
+ | over time and now can use different versions using various ciphers and encryption standards. | ||
+ | |||
+ | NetYCE always used the default SSH protocols and ciphers that was installed op the operating | ||
+ | system, and those defaults changed when moving from CentOS/ | ||
+ | |||
+ | To avoid no longer being able to connect to devices due to a change in supported SSH settings, | ||
+ | the default SSH configuration is now overruled by a configuration file that will incorporate | ||
+ | all available features of the SSH version running. Since this applies strictly to **outgoing** | ||
+ | connections there is no security impact as it is the receiving device that determines the | ||
+ | acceptable protocols. | ||
+ | |||
+ | The SSH configuration file is ''/ | ||
+ | administrator when desired. This configuration will __only__ be used by NetYCE jobs, for | ||
+ | cli-based sessions the default system SSH config file ''/ | ||
+ | |||
+ | Note: NetYCE uses the system SSHD configuration file ''/ | ||
+ | **incoming** connections. | ||
+ | </ | ||
+ | |||
+ | === Form permissions === | ||
+ | <WRAP indent> | ||
+ | When NetYCE denied the user access to a menu, form or tool, it was not always obvious that | ||
+ | insufficient permissions were the reason for a lack of response or a prompt (re-login) to | ||
+ | provide better credentials. | ||
+ | |||
+ | The various cases were evaluated and modified to provide the user with a consistent message | ||
+ | reporting //"You do not have permissions to view this page"// | ||
+ | |||
+ | Some inconsistent privileges were corrected. | ||
+ | </ | ||
+ | |||
+ | === Parsing Template test === | ||
+ | <WRAP indent> | ||
+ | When we introduced the command parsing with its own set of templates, we also added a tool to | ||
+ | assist the engineer to create these command parsing templates. This ' | ||
+ | located in the ' | ||
+ | |||
+ | Because it was considered more logical to have it available as an operational tool, it was | ||
+ | relocated to the ' | ||
+ | </ | ||
+ | |||
+ | === Scenario assignments === | ||
+ | <WRAP indent> | ||
+ | When the scenarios were extended with the support for variables, support for nested and | ||
+ | indirect variables was included. This allowed for a very flexible definition of variables | ||
+ | where even the order of the definition of a variable was properly ' | ||
+ | define for example ''< | ||
+ | later, or even change them within a loop. | ||
+ | |||
+ | However, this ' | ||
+ | resulting in failed tests values or ' | ||
+ | the same value! | ||
+ | |||
+ | Since these out-of-order value assignments are for most people counter-intuitive, | ||
+ | make all assignments in the scenario (like <var> := < | ||
+ | indirect values - if defined. The variable references that do not yet exist are maintained. | ||
+ | The resulting variables will then contain their expected values and still support the out-of-order | ||
+ | definitions if needed. | ||
+ | |||
+ | To properly support any as yet ' | ||
+ | missing values are substituted for the comparison but do not alter the variable value permanently. | ||
+ | This allows to still benefit from any out-of-order definitions and loop constructions if desired | ||
+ | or already in place. | ||
+ | </ | ||
+ | |||
+ | |||
+ | \\ | ||
+ | <WRAP widths 60% box safety> | ||
+ | ==== Fix ==== | ||
+ | </ | ||
+ | |||
+ | === F5 BigIP fixes === | ||
+ | <WRAP indent> | ||
+ | Several issues dealing with the F5 BigIP vendor module have been fixed: | ||
+ | * At login the ' | ||
+ | * Depending on version, the backup ' | ||
+ | * When a login failed, the log did not show for with user name | ||
+ | </ | ||
+ | |||
+ | === Huawei fixes === | ||
+ | <WRAP indent> | ||
+ | A problem when saving a configuration for backup or NCCM purposes failed. This issue is fixed. | ||
+ | </ | ||
+ | |||
+ | === Cisco censoring === | ||
+ | <WRAP indent> | ||
+ | When a device configuration from the NCCM environment is shown on-screen, the NetYCE system | ||
+ | will hide security sensitive information like passwords for operators lacking the privileges. | ||
+ | This censoring mechanism uses keywords and patterns to find these phrases to be censored. | ||
+ | |||
+ | An update to the Cisco IOS and XE vendor modules was made to improve the recognition of | ||
+ | snmp-server configurations for snmp-v3. | ||
+ | </ | ||
+ | |||
+ | === NCCM database restore === | ||
+ | <WRAP indent> | ||
+ | NCCM databases could fail to be restored where an error in compatible patchlevels was incorrectly | ||
+ | reported. This issue was fixed. | ||
+ | </ | ||
+ | |||
+ | === Template AND conditions === | ||
+ | <WRAP indent> | ||
+ | In templates, conditions can be combined to create ' | ||
+ | When used to test on multiple variables without compare values as in this example, inconsistent | ||
+ | results were produced if one of the variables had no value. These results also made the | ||
+ | repeat conditions (' | ||
+ | |||
+ | These issues were resolved. | ||
+ | </ | ||
+ | |||
+ | === Template comments === | ||
+ | <WRAP indent> | ||
+ | Templates can use several types of comment characters ('#", | ||
+ | beginning of a comment line. The comment lines in templates are dropped from the generated | ||
+ | configuration, | ||
+ | comment lines are included in the generated configuration. | ||
+ | |||
+ | These included comment lines may contain variables to be substituted to make the comment | ||
+ | clearer. However, when a sub-template was ' | ||
+ | would still include the parsed sub-template - with the initial line commented out. | ||
+ | |||
+ | This was fixed by only parsing only the vendor comment lines and protecting the template | ||
+ | brackets by including backslashes (' | ||
+ | |||
+ | **Update**: The introduction of this vendor comment line handling was observed to introduce an | ||
+ | unwanted side effect: Template blocks (lines ending in backslashes ' | ||
+ | as a unit) with multiple templates would result in only the first template to be expanded, the | ||
+ | remainder to be commented out. By reworking the multiline parsing and extending the comment | ||
+ | handling resolved this issue. | ||
+ | </ | ||
+ | |||
+ | === Unexpected device prompts === | ||
+ | <WRAP indent> | ||
+ | Vendor modules using the device CLI sometimes are confronted with unexpected prompts. These prompts | ||
+ | are handled automatically by accepting the default using an ' | ||
+ | when these defaults were not used and the CLI demanded a typed answer, the job would not properly | ||
+ | timeout as was the case in previous NetYCE releases. | ||
+ | |||
+ | This issue is now fixed. | ||
+ | </ | ||
+ | |||
+ | === OS upgrade file-sizes === | ||
+ | <WRAP indent> | ||
+ | Over the years file and file-system sizes have grown. Since NetYCE stores the OS-upgrade file sizes and | ||
+ | disk spaces in bytes, the limit of regular integer databases columns are no longer sufficient for storing | ||
+ | the now common numbers. | ||
+ | |||
+ | The limit of 4.2 GB is now raised to 18 PB (yes, Peta-bytes) by redefining the relevant database columns. | ||
+ | </ | ||
+ | |||
+ | === Rebooting HP C7 devices === | ||
+ | <WRAP indent> | ||
+ | A problem where the scenario command '' | ||
+ | reboot was fixed. Answering an additional prompt and a timing issue resolved the problem. | ||
+ | </ | ||
+ | |||
+ | === SFTP transfers === | ||
+ | <WRAP indent> | ||
+ | Most networking jobs will use SFTP as the preferred file transfer method. NetYCE uses a secured | ||
+ | SFTP environment involving ' | ||
+ | ''/ | ||
+ | |||
+ | It now has become apparent that this standard configuration file uses some performance limiting | ||
+ | settings which allows only one session at the time at limited bandwidth. | ||
+ | |||
+ | An updated SFTP configuration file will be automatically installed when updating the software, | ||
+ | but might require modifications on some systems. The new configuration limits the total SFTP bandwidth | ||
+ | to the devices (download) to 100 Mbps with a max of 10 Mbps per session up to 50 parallel sessions. | ||
+ | These settings were chosen to prevent poor performance for users when massive OS-upgades are in | ||
+ | progress. See the Wiki article [[maintenance: | ||
+ | </ | ||
+ | |||
+ | === Highest port-id === | ||
+ | <WRAP indent> | ||
+ | When adding ports, a maximum value of 256 for the port-id was used in the GUI. Plenty for | ||
+ | ordinary devices but no longer for high-density devices. The same maximum value also | ||
+ | applied to port-channel ports which supports values up to 4k. | ||
+ | |||
+ | These limits for physical and logical port-ids are now raised to 99.999. Since the node | ||
+ | slot port-overview is limited to 150 icons an icon with ' | ||
+ | port-ids then shown are present. | ||
+ | </ | ||
+ | |||