User Tools

Site Tools


maintenance:releases:active_build

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
maintenance:releases:active_build [2019/11/13 16:29]
yspeerte
maintenance:releases:active_build [2019/12/04 15:07] (current)
yspeerte
Line 1: Line 1:
 +===== NetYCE 7.1.1 Active_build =====
 +===== Release notes =====
 +Date: 2019-12-04
 +
 +> <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:​downloads:​system_updates:​system_updates|Download Patchfiles]] article.
 +</​color>​
 +
 +\\ 
 +<WRAP widths 60% box safety>
 +==== Enhancement ====
 +</​WRAP>​
 +
 +=== 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 compliancy 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 <​Node_model>​ and <​Software_version>​.
 +</​WRAP>​
 +
 +=== Scenario '​Split'​ function ===
 +<WRAP indent>
 +The '​split'​ function was added to the scenarios. This function allows a string or variable to be 
 +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.
 +</​WRAP>​
 +
 +=== 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,​ node job-locking is added to the scheduler. This function will
 +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 '​wait'​ which is highlighted using a yellow background.
 +
 +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 '​wait'​ state, the job is set '​suspended'​ in the assumption that its maintenance slot
 +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 
 +'​Sched_ignore_locks'​. The job activation mechanism will then function as in previous releases.
 +</​WRAP>​
 +
 +=== SSL hardening ===
 +<WRAP indent>
 +The NetYCE front-end can be set-up to use the unencrypted '​http'​ or the encrypted '​https'​. When using
 +https, a SSL-certificate must be created and installed. To further strengthen the security offered by
 +https and the certificate,​ the protocol and encryption ciphers can be chosen to offer best protection.
 +
 +By default NetYCE accepts TLS1, TLS1.1 and TLS1.2. An additional setting in '​yce_setup'​ allows the 
 +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 ''​yce_setup.pl''​ script and answering '​Y'​ to the '​SSL-hardening'​ prompt will
 +the '​TLS1.2-only'​ access be configured on the system. A '​N'​ to this prompt will configure access
 +for TLS1, 1.1 and 1.2. The older SSL2 and SSL3 levels wil always be disabled.
 +
 +<​code>​
 +YCE server roles:
 +  #  Hostname ​        ​Front-end ​   SSL     ​HTTPD ​    ​URL ​     Mojo     ​Database ​    Id
 +* 0) yce-one ​         yes          https   ​root ​     name     ​8080 ​    ​yes ​         1
 +  Select the server# to change, '​C'​ to continue: [0]
 +    '​yce-one'​ is (also) a Front-end server? [Y]
 +    '​yce-one'​ is DNS resolvable (y/n)? [Y]
 +    '​yce-one'​ uses SSL (y/n)? [Y]
 +    '​yce-one'​ uses SSL-hardening (y/n)? [Y] ?
 +      enter '​y'​ for TLS1.2 only, or '​n'​
 +    '​yce-one'​ uses SSL-hardening (y/n)? [Y] y
 +</​code>​
 +
 +</​WRAP>​
 +
 +=== 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 '​a'​ NetYCE system would spontaneously force a logout or
 +deny access to a tool due to '​permissions'​.
 +
 +The underlying cause was that customers use various NetYCE environments for '​production'​ and '​testing'​.
 +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,​ but the '​proof'​ of logging in, the session-id, is not present in that database.
 +
 +The SSO function has now been redesigned to permit access across environments. The session-id does
 +not have to be present in the '​guest'​ environment to be validated and accepted - provided the user-id
 +exists in both environments and use the same password. If the users' permissions differ across ​
 +the environments,​ they will be applied according the environment he is working in.
 +</​WRAP>​
 +
 +=== 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
 +''​https://​genesis.netyce.org/​report/​Report_name''​. This results in a csv file in Unix format,
 +but can be converted to Dos using ''​https://​genesis.netyce.org/​report/​Report_name&​type=dos''​
 +
 +The scheduled execution of the reports is balanced (by number of reports) over the available ​
 +servers and still uses the standard Unix '​cron'​ to support the existing scheduling intervals.
 +</​WRAP>​
 +
 +=== Ping tool ===
 +<WRAP indent>
 +A new '​ping'​ tool was build to replace the existing '​ping'​ and '​ping6'​ tools. Where previously only
 +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 '​-'​ for each failed ping.
 +</​WRAP>​
 +
 +
 +\\ 
 +<WRAP widths 60% box safety>
 +==== Change ====
 +</​WRAP>​
 +
 +=== backslash '​\'​-protection in scenarios ===
 +<WRAP indent>
 +When using templates and scenario'​s,​ some characters have special meaning. These are used in templates to
 +indicate a conditional configuration line (using ''​|..|''​) or a sub-template to be substituted (using ''​{..}''​).
 +And in scenarios to indicate a special operator (like \s\d\r\n) in regex conditions (e.g. ''/​^\s*\d+/''​).
 +
 +To prevent these characters form being interpreted as a template operator and just type the character,
 +backslash-protection is used. The string ''​{name}''​ refers to the template '​name'​ but the string ''<​color red>​\</​color>​{name<​color red>​\</​color>​}''​
 +refers just to the string and will output ''​{name}''​.
 +
 +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 ''/​^\\\\s*\\\\d+/''​.
 +
 +This less-than-desirable behaviour 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 ''​\n''​ for a return or a ''​\t''​ for a tab are substituted where expected.
 +
 +> **Important**:​ The modified processing of backslash-protection might result in some existing scenarios to fail. Multiple sets of backslashes (''​\\\\''​) will result in, indeed, backslashes (''​\\''​). These scenarios need to be reviewed and tested.
 +</​WRAP>​
 +
 +=== 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/​RedHat version 6 to version 7.
 +
 +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 ''/​opt/​yce/​etc/​ssh_config''​ and can be modified by the server
 +administrator when desired. This configuration will __only__ be used by NetYCE jobs, for
 +cli-based sessions the default system SSH config file ''/​etc/​ssh/​ssh_config''​ is used.
 +
 +Note: NetYCE uses the system SSHD configuration file ''/​etc/​ssh/​sshd_config''​ for its 
 +**incoming** connections.
 +</​WRAP>​
 +
 +=== 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.
 +</​WRAP>​
 +
 +
 +\\ 
 +<WRAP widths 60% box safety>
 +==== Fix ====
 +</​WRAP>​
 +
 +=== F5 BigIP fixes ===
 +<WRAP indent>
 +Several issues dealing with the F5 BigIP vendor module have been fixed:
 +  * At login the '​tmos'​ shell was not detected
 +  * Depending on version, the backup '​no-passphrase'​ argument was unknown
 +  * When a login failed, the log did not show for with user name
 +</​WRAP>​
 +
 +=== Huawei fixes ===
 +<WRAP indent>
 +A problem when saving a configuration for backup or NCCM purposes failed. This issue is fixed.
 +</​WRAP>​
 +
 +=== 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.
 +</​WRAP>​
 +
 +=== 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.
 +</​WRAP>​
 +
 +=== Template AND conditions ===
 +<WRAP indent>
 +In templates, conditions can be combined to create '​AND'​ conditions (e.g. '​|<​var1>​||<​var2>​|'​). ​
 +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 ('​||'​ and |!|') unpredictable.
 +
 +These issues were resolved.
 +</​WRAP>​
 +
 +=== Template comments ===
 +<WRAP indent>
 +Templates can use several types of comment characters ('#",​ '​!',​ '​--'​) that mark the 
 +beginning of a comment line. The comment lines in templates are dropped from the generated ​
 +configuration,​ save the lines starting with the character used by the device vendor. These 
 +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 '​commented out' using this method, the configuration
 +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 '​\'​ form blocks and are parsed ​
 +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.
 +</​WRAP>​
 +
 +=== 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 '​enter'​. It was noted however, that
 +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.
 +</​WRAP>​
 +
 +=== 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.
 +</​WRAP>​
 +
 +=== Rebooting HP C7 devices ===
 +<WRAP indent>
 +A problem where the scenario command ''​reboot''​ for HP Comware-7 systems would not properly
 +reboot was fixed. Answering an additional prompt and a timing issue resolved the problem.
 +</​WRAP>​
 +
 +=== SFTP transfers ===
 +<WRAP indent>
 +Most networking jobs will use SFTP as the preferred file transfer method. NetYCE uses a secured
 +SFTP environment involving '​MySecureShell'​. The configuration file for this environment,​
 +''/​etc/​ssh/​sftp_config'',​ is created on server installation based on the distributed version.
 +
 +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:​general:​file_transfer_account_setup#​scp_and_sftp_setup|File-transfer Account setup]] for details.
 +</​WRAP>​
 +