[Fixed in 2.1.0] Copy Run Start

Unimus support forum
Post Reply
KTunimus
Posts: 2
Joined: Tue Mar 02, 2021 6:40 pm

Tue Mar 02, 2021 6:53 pm

Testing out Unimus and I have run into a very stupid problem on my end. I assume I am just goofing something up but it is frustrating me because I know I will run into issues with prompts in the future.

So extremely basic test, push the command copy run start and I get a Interaction error with the following output.

3850sw#copy run start
Destination filename [startup-config]?
TIMESTAMP: 2021-03-02 18:39:02.806
<<SSH disconnect - channel & session>>
DEVICE OUTPUT END:

I have tried adding $[enter] but that has not helped.

Also curious what the ETA is on variables in the config push product?
User avatar
Tomas
Posts: 983
Joined: Sat Jun 25, 2016 12:33 pm

Tue Mar 02, 2021 9:43 pm

As per documentation, the correct sequence should be this:

Code: Select all

copy run start$[no-wait]
$[enter]
The $[no-wait] tells Unimus to not expect any known inputs (normally a prompt, or a y/n question, etc.), but to immediately proceed to next command. The behavior is fully documented here: https://wiki.unimus.net/display/UNPUB/M ... ttodevices

There is an example of setting MOTD on a device later on in the Wiki article that goes into more details, which is the same principle as what you are trying to do :)
KTunimus
Posts: 2
Joined: Tue Mar 02, 2021 6:40 pm

Wed Mar 03, 2021 2:07 pm

Thanks for the fast reply Tomas, but I still get an interaction error.

Code: Select all

copy run start$[no-wait]
$[enter]
HEADER:
Address: 10.150.0.6
Zone number: 0
Job type: PUSH
Job started: 2021-03-03 14:05:21.138
Job finished: 2021-03-03 14:05:43.159
DEVICE OUTPUT START:
<<SSH connect - socket>><<SSH disconnect - socket>>SSH-2.0-Cisco-1.25
<<SSH connect - session>><<SSH connect - shell channel>>
3850sw#
TIMESTAMP: 2021-03-03 14:05:23.098

3850sw#copy run start
Destination filename [startup-config]?
TIMESTAMP: 2021-03-03 14:05:43.154
<<SSH disconnect - channel & session>>
DEVICE OUTPUT END:
User avatar
Tomas
Posts: 983
Joined: Sat Jun 25, 2016 12:33 pm

Thu May 13, 2021 10:25 pm

Update on this issue - this has been solved in 2.1, we found an edge-case where "$[no-wait]" would not work.
In 2.1 and newer this should work as expected :)
Post Reply