[BETA] 1.7.0 beta thread

[Tomas]

UPDATE: 1.7.0 has been released, and this topic has been locked.

This is a beta release of version 1.7.0-beta4 intended for testing purposes.

This Beta contains many new features, but mainly:
- mass config push / device interaction (the ability to push commands to many devices easily)
- credentials binding (use only one particular credential on a device)
- enable passwords (specify a list of enable passwords, rather than Unimus using just users password to switch to enable / configure)
- enable password binding (use particular enable password on device - by default enable password is discovered)
- subnet scanning (device import / discovery by scanning subnets)

We highly encourage you to read the entire Changelog below.

Here is an example of the Config Push feature:
(right click -> open image in new tab for full resolution)


We test the beta releases as best as possible, but bugs may be present.
For general usage, we recommend customers run current STABLE release.

You can download the Beta build here:
https://goo.gl/BSZgn8

Changelog:

Code: Select all

= Version 1.7.0 =
Features:
  Improved configuration change detection on Cisco IOS and Cisco NXOS
  Unimus now detects when devices return "permission denied" / "access denied" errors and fails the backup job
  Improved error reporting in Dashboard "Show log" for all jobs
  Improved logging of various errors and failed jobs in the log file
  Improved Enable/Configure mode switching for all supported vendors
  Added detection of command unsupported and permission denied error in output of devices that do not use paging

  Added a new "Mass config push" / "Mass reconfig" feature:
    - Unimus is now able to push configuration to your devices
    - you can create as many "push presets" as needed to automate your network
    - devices will be switched to Enable or Configure mode automatically if a push preset requires it
    - output from the push job is grouped, no need to check output of each device manually

  Added support for Enable/Configure passwords separate from Credentials (username/password combinations):
    - you can specify a list of Enable/Configure passwords on the Credentials screen
    - Unimus will automatically discover which Enable/Configure password is valid for a device

  Added support for Credential and Enable/Configure password binding:
    - you can bind specific Credentials or Enable/Configure passwords to devices
    - this will disable Credential and Enable/Configure password discovery on the device
    - only the bound Credential and Enable/Configure passwords will be used for the device
    - discovery, backup and any other operations on the device will fail if the bound Credentials are invalid

   Added a new "Network scan" (device discovery) feature
     - Unimus is now able to adopt devices by scanning your network
     - you can define multiple subnets for scanning, and Unimus will find available devices
     - networks scans can be scheduled to periodically adopt devices from the network

  Added support for:
    - Brocade NetIron
    - HP 1950 switches
    - Ruckus Unleashed

Fixes:
  Devices with very long backup time (3+ minutes) would not be backed up
  Fixed discovery not working when quickly removing and then re-adding the same device
  Fixed Citrix NetScaler driver not working with newer versions of NetScaler
  Fixed connections sometimes failing to slow devices
  Fixed missing scroll-bar in "View backup"
  Fixed wrong backup's table columns width
  Fixed account with READ_ONLY role could access 'Adding the first device' screen

Known issues:
  Special characters can be replaced by '?' under specific circumstances

[Tomas]

1.7.0-beta2 is released today.
Original post updated to reflect this.

Changes from beta1:

Code: Select all

Features:
  "Mass config push" feature upgrades:
    - fixed issuing certain commands in "enable" mode causing push to fail
    - fixed "configure" mode switching not working for some vendors
    - pagination will now be properly removed in the "Output" window
    - changing the hostname of the device during config push will no longer cause it to fail
    - improved formatting in the "Output" window

  Added support for:
    - Ruckus Unleashed

[Brambb15]

Saw your post on the MT forum.
Feature works great!

But maybe a option to tell Unimus not to expect output?

When I use the following 'code' to upgrade remote router I get interation_error, which is probably cause the router is rebooted immediately after the commands are pushed?

unimus_routeros_ugprade.png (49.6 KiB) Viewed 26536 times

[srh]

The mass config push function is great. I used it to push a line of configuration out to 45 Cisco switches and it worked as expected. For devices that require an additional command to save after sending the configuration (IOS "write mem"), I would suggest adding a checkbox next to the "Require enable" and "Require configure" for "Save Configuration after Successful Push".

Great work!

[Tomas]

But maybe a option to tell Unimus not to expect output?

When I use the following 'code' to upgrade remote router I get interation_error, which is probably cause the router is rebooted immediately after the commands are pushed?

Indeed, Unimus considers connection loss as a failure, but in your case it is expected since the router reboots.

Will add an option for this.

For devices that require an additional command to save after sending the configuration (IOS "write mem"), I would suggest adding a checkbox next to the "Require enable" and "Require configure" for "Save Configuration after Successful Push".

This would indeed be useful, but will require some implementation time.
(we need to go over all 90 supported vendors and check if they have a concept of "save config" and what the proper command is)

Ticket created:
https://tracker.unimus.net/browse/UN-320

[lweidig]

We are VERY excited for the features in this version and are starting to work on the mass config option for our network. One enhancement that would be AWESOME is if when you select devices that you could pick NetXMS container names and then it would maintain that list of devices that this applies to based on that. Would just help to provide us with more reliable automation as the containers we use / import would insure that all devices are there and over time we do not miss any or leave ones that are not valid any longer.

How about widening the command entry window as well from the web site. Much easier to visualize if there is not so much wrapping taking place. Likely most people these days have pretty decent resolution displays for this stuff and not the sort of thing you are likely (though I am sure some will) do mobile.

Also, assuming that we will at some point be able to schedule these items to run?

What about options to create some sort of script repository as well or add a forum section so that people can discuss this and share what is working.

Thanks for the advances, so glad to be using this product and looking forward to its future which has a lot of great features planned!

[lweidig]

Ok, so we are following the Mikrotik mass updater to get our feet wet and it is something we would want going forward anyhow. During the first step where you push out the upgrade-package-source after testing it on one device (and then deleting it) we selected a group of about 20 devices. After running now we had:

COMMAND_NOT_SUPPORTED 1
CONNECTION_ERROR 1
Output-1 10

The one device that came back with COMMAND_NOT_SUPPORTED was the same ROS version as the other devices and indeed when we logged into the device the configuration was setup properly.

Not sure on the CONNECTION_ERROR as the router is definitely online and accessible from the Unimus server. We logged in from there and it did NOT have the configuration change made.

The command is now stuck in a running state and of course there are 8 unaccounted for devices!

Let me know what information you would like from the system to help figure out what might be happening. Thanks!

[Tomas]

The one device that came back with COMMAND_NOT_SUPPORTED was the same ROS version as the other devices and indeed when we logged into the device the configuration was setup properly.

There must have been some output from the device that Unimus recognized as an error.
I think the best approach would be to show output even for error groups, so debugging is easier.

The command is now stuck in a running state and of course there are 8 unaccounted for devices!

The config push should time out after about 30 seconds.
Then a new group called "INTERACTION_ERROR" should be created for the devices that communication timed out with.

Did this happen, or did the push stay frozen in RUNNING state forever?

[lweidig]

It remained and remains in the RUNNING state! Yes, I agree you need to show the log for the failed ones as well as the ones that do not fail so we have something to go on.

Like I mentioned originally though the "failed" one actually succeeded and the commands ran as it was there if I looked at the device and exported the configuration.

What about thoughts on the other items?

Here is all it logged (21 devices correct, not sure where 30 comes from):

2018-05-01 13:03:34.097 INFO 477686 --- [https-jsse-nio-209.103.224.97-443-exec-3] net.unimus.business.core.CoreClientImpl : Running device interaction for 21 devices
2018-05-01 13:03:34.124 INFO 477686 --- [https-jsse-nio-209.103.224.97-443-exec-3] net.unimus.core.api.CoreImpl : Running configuration push to 30 devices
2018-05-01 13:03:36.981 WARN 477686 --- [interact-26] n.u.c.service.cli.CliInteractionService : Config push to 'XXXXXXXXX.excel.net' failed - 'Command not supported by device'!

[lweidig]

This morning that job was now IDLE, but nothing more got logged including the list of devices that were not updated. My guess is that the other standard backup jobs running pushed the status to IDLE.

However, this brings me to another feature suggestion for this and that is the ability for Run Now to run against only failed / skipped devices via some sort of option. This was you can run the job multiple times without updating the working units over and over since this may cause a failure as it would here since the host is already added for the package source.