Two new vendor-modules were added. Support for Gigamon GigaVUE and Meinberg LTOS was added bringing the total of supported Vendor device families up to 33.

When retrieving the configuration for a node through screen scraping we wont check for error messages when screen scraping anymore, therefore avoiding false positives.

When you push a startup config we make sure to first backup this config before rebooting the node so our config backup tool also has the most recent configuration stored as such.

When retrieving the configuration of a node using the nccm daemon, now also filtering out ever-changing lines before comparing it agains previously saved configuration to prevent false diff messages.

Sending a notification using syslog when the backup of config fails / succeeds either through filetransfer of screen scraping.

As was already available using the various API's, a 'new' configuration' for a device can now also be manually uploaded using the GUI. The new “Upload config” button can be found using the “Backups” form when opening the “details” of a node.

Note that the uploaded configuration will be added to the Nccm history as the 'latest' version.

The polling groups form has been re-skinned with the new layout. Functionality remains virtually the same.

The backup details form has a button added that allows you to upload a configuration manually for a node.

The dropdowns for countries and states in the sites edit form now contain data for a number of countries: United Kingdom, United States, Germany, France, Belgium, Luxembourg and Ireland.

The domain name field in the database has been lengthened from 20 to 100 characters.

Config parsing has been deprecated. Every of its functions can be done using Command Parsing.

You can now enable and disable compliance rules.

The graph-button from the client and site grids have been removed.

A new method for log rotation, using the logrotate linux tool has been implemented.

When a delete BOP service order is processed, we now wait with deleting the data from NetYCE until BOP has confirmed that the order has actually succeeded.

Support has been built in for BOP Line Transfers. Node name changes are now properly handled with the right mapping files.

The number of messages that we detect from BOP to determine if a request has gone wrong has been increased. We now also listen for if the service order cannot be found in bop, an error in routing policy, and if the service is already in use in the transport connection circuit.

Support for the action 'migration', as next to 'modify' is now available for BOP service orders.

The job logs form now no longer expands a job's log when you click on it. Instead it just opens the full popup with all data.

The command job form now provides links for scheduled jobs, that immediately opens a popup for their job files.

The sidebar on the GUI has been rewritten, as the original library used has been deprecated.

The config_diff scenario call was outdated. It was originally meant to pull the config of a node and compare it to what we have in the database. However, beforehand we already always retrieve the config anyway, leading this function to always return true. The command has been simplified so that it won't compare anymore, but running this command will just pull the latest config from the node.

Whenever a node's backup polling status is set to disabled, a syslog message is sent.

You can now toggle marked configs on or off in the config diff form.

If an email is being sent after a compliance check, the email body now contains the report body. (Truncated for very long reports).

The config restore button in the backups form now reboots the node after successfully restoring the configuration. It also now comes with a warning for users that any unsaved changes on the node will be undone.

The node name change form was needlessly complex. At the moment you can simply change the node name you want, without any restrictions from its node type.

Currently our conditions support a couple of options which only work when the Rule Start and/or Rule End are used. Therefore will now hide those options when one of those fields are blank.

We have hidden the must contain lines and order options from compliance conditions that deal with the full config. We have also hidden the comments for ConfigText conditions.

The 'yce_setup' allows for choosing a 'hardening' of the available SSL/TLS versions and ciphers. However, only the Apache server on port 443 would limit the ciphers validated as 'strong'. The backend API's on port 8080/8443 ('mojo' for the gui) and 8880 ('xchrest' generic api) still allowed weaker ciphers like RC4.

The configurations for the 'mojo' and 'xchrest' backend api's have been modified to use the same restricted 'strong' ciphers that were configured for the Apache web server.

• Export_action_logs log file is /var/opt/yce/logs/yce_action.log
• Export_config_logs log file is /var/opt/yce/logs/yce_config.log
• Export_task_logs log file is /var/opt/yce/logs/yce_task.log

http directory (/var/opt/shared/public/http/) to be used without authentication through download.pl.

The http directory is a special case, files in this directory can be accessed without authentication. Be aware that you should not put any sensitive data in this directory for this reason.

The tool to search for a string in a large number of configurations, “Config Search”, is now integrated in the “Backups” dashboard. The new boxes for the Config search and its Results can be found below the Nodes grid of this page.

Some simplifications could be made as the node selection is largely accomplished using the filters of the node grid, but otherwise the functionality of the tool is unchanged.

When you created or edited a command rule, the behaviour used to be that whenever the daemon made a compliance check before the new command had been retrieved, it would mark the conditions in the rule as temporarily non-compliant. This was very annoying if you had set signals on non-compliance, because it would flood your system with non-issue calls. We now treat a rule as compliant for the time being until its command rule has been retrieved, and when you edit a command rule its older outdated reply will be removed from the database, in order to mitigate this issue.

The template form is now blank until you select a client type somewhere, instead of showing a bunch of empty grids.

Our infoblox adaptation has two new options: add_static-dhcp and clear_static_dhcp. These support Infoblox's statid dhcp objects.

When changing the Domain value of a node, this change did not result in a re-scheduling of a compliance check. For most compliance policies the actual Domain assigned to a node is not relevant as the Domain is primarily used to retrieve the credentials needed to the configuration retrieval. But when policies use conditions where the configuration is tested against actual values associated with the Domain, a Domain change becomes very relevant for the compliance results.

Conditions in policies can access NetYCE variables using the <variable> syntax causing the condition to test against associated data. As the Domain is often used as such a source, compliance re-scheduling for the affected node is worthwhile. Therefore, the NCCM refresh flag now gets set when re-assigning a Domain of a node.

Of course, many other NetYCE objects other than Domain can be used in the conditions, and these will not trigger this compliance re-scheduling. For those cases the intended setup involves scheduled compliance policies that will be executed at fixed intervals regardless of changed variables or assigned objects.

Configuration backups (Nccm) are normally retrieved from the network devices. For migration or integration purposes these configurations can also be submitted using the Xch api. However, when doing so for a new device, the new device and its config would not be displayed in the Backups form. Only after a different trigger to renew the polling selection (like adding a cmdb node manually) would the node show up in the grid.

Additionally, the Xch nccm submit call was extended to include a new optional attribute, nccm_polltime, to override the polling timestamp of the submitted configuration. However, as with GIT and other 'diff' based storage engines, the NCCM cannot process submitted configurations out-of-order. The provided polling timestamps are mostly administrative and the submitted configuration is still considered the 'latest' superseding the previous. The option is useful mostly to submit a series of configurations taken at different historical moments.

Although executing a Command job on a node automatically creates configuration backups, the Nccm / Compliance was not triggered to re-evaluate any config changes this job accomplished.

Now, when a job completes, regardless of status, will cause the Nccm and Compliance to be triggered.

The config diff form in the Backups section had some layout issues when viewed in an extra wide or extra small window. This has been fixed.

When you lost a session in a form in the old layout, you were still redirected to the old login page. You now will be redirected to the new login page.

The grids in the Compliance Dashboard section accidentally sorted their numerical columns as if they were strings. They are now sorted numerically.

A number of forms were vulnerable to Cross-Site-Scripting and SQL Injection attacks. This has been fixed now.

When a condition that checks on a Software Version, Hostname or Node Model is not compliant, its report mentioned '<full_config>'. This now has been changed to '<software_version>', '<hostname>', and '<node_model>' respectively.

When a lot of nodes had their backups changed at the same time, leading to subsequent compliance checks, there was a bug where not all of them would be scheduled for compliance, therefore leading to an outdated compliance set. This has been fixed now.

The rule start and rule end of a compliance rule sometimes were evaluated case sensitively, and sometimes not. They are now always evaluated case insensitive.

The first column of the Custom Data form sometimes had its search field removed. This is fixed.

The “Run compliance on config change”-checkbox has been fixed.

The CMDB Region relation had a bug in it where it always would use the default region, causing you to not be able to specify custom regions. This is fixed.

The relation test broke when trying to use a relation with context functions. This is fixed.

When you delete a node group, its compliance node groups are now deleted as well.

The link to the wiki in the right sidebar accidentally opened two windows with the wiki. This has been reduced to one.

Setting the maximum number of timeouts for the backups daemon to put a node to disabled was wrong if it had a default value. This is fixed.

Compliance's block detection's rule start did not work with cleartext values. This is fixed.