Upgrade, Automation, & Compliance Features

[bwebb]

1. In planning some more complex operations in Mass Config Pushes we've run into scenarios where having an option to ignore failed command inputs would be very helpful. Currently any failed command will cause the script to fail or at least show invalid command in the device output where sometimes a script may be designed around differing platforms or versions with expected failure scenarios.
2. Alternatively if we were able to utilize some sort of if/then/else functionality the same could be accomplished.
3. Some sort of compliance checks or reports that could be run on a scheduled basis would be amazing. Even if these are custom designed only and there are no templates included we would be able to write something to check for things like telnet disabled, ssh enabled, management ACLs, switchports that are down but not admin down, version greater than X, etc.
4. Ability to auto-upgrade Cores when the Server version is upgraded or to push upgrades to Cores. We've got a few hundred customers but we've been holding off on pushing to all customers because even with 17 remote cores at this point it is not a simple process to upgrade. We do utilize a tool that could use PowerShell and Invoke-WebRequest to download the file using a remote agent we have installed but this doesn't work because your download filename includes a space in the link (https://download.unimus.net/unimus-core/-%20Latest/Installer-Core.exe)

Thanks!

[Tomas]

• In planning some more complex operations in Mass Config Pushes we've run into scenarios where having an option to ignore failed command inputs would be very helpful. Currently any failed command will cause the script to fail or at least show invalid command in the device output where sometimes a script may be designed around differing platforms or versions with expected failure scenarios.

This is definitely planned. There will be a new "ignore-error" behavior modifier which will ignore failures for a command. Current plan is to deliver this in 2.3.0 (Q3-Q4 this year). On the Roadmap this is under "New Config Push behavior modifiers and functions".

• Alternatively if we were able to utilize some sort of if/then/else functionality the same could be accomplished.

We do want to do this (introduce some easy DSL / scripting logic within Config Push), but currently no ETA yet.

• Some sort of compliance checks or reports that could be run on a scheduled basis would be amazing. Even if these are custom designed only and there are no templates included we would be able to write something to check for things like telnet disabled, ssh enabled, management ACLs, switchports that are down but not admin down, version greater than X, etc.

This will be possible when we have the "Export / Send results" functionality in Config Push. You will be able to get a .yaml (or a .html) file with full push results - and you will be able to parse that for anything you need.

• Ability to auto-upgrade Cores when the Server version is upgraded or to push upgrades to Cores. We've got a few hundred customers but we've been holding off on pushing to all customers because even with 17 remote cores at this point it is not a simple process to upgrade. We do utilize a tool that could use PowerShell and Invoke-WebRequest to download the file using a remote agent we have installed but this doesn't work because your download filename includes a space in the link (https://download.unimus.net/unimus-core/-%20Latest/Installer-Core.exe)

You should be able to use the latest link even with the "%20" in there. For example, in Linux "wget https://download.unimus.net/unimus/-%20 ... taller.exe" works without issues.

Alternatively, you can use a versioned link - for example https://download.unimus.net/unimus/2.2.2/Installer.exe. For each release, we publish it on "latest" and under its version. As a note - you can get any past Unimus version by simply substituting the desired version in the above link.

[Fabpicard]

We do want to do this (introduce some easy DSL / scripting logic within Config Push), but currently no ETA yet.

Hi Tomas,

I see that the "New Config Push behavior modifiers" takes you long more time, then expected inside this topic

Currently, instead of some "graphic-bugs" (I report them seperate after upgrading all our installations), there is for us currently only a "if/then/else" inside the mass-config-push missing :/

As you know, the HPE/Aruba-CLI is very strange but also simple...
It would be perfect to have it like this (or similar )


vlan 2
name "LAN"
tagged "${uplinks}"

$if ${core}=yes
vlan 3
name "Server"
tagged "${uplinks}"
$endif


So that we can "script" by the device-variable, which switch will get which vlan... Or make a change if ports are tagged/untagged at different switches but everywhere at the uplink-ports

Greetings Fabian