...

To perform a push, you first need to create a "Push Preset" from the Mass Config Push home page. For the "Commands", you can provide the same sequence of commands and key-strokes to Unimus as you would when interacting with the device CLI manually.

After a preset is created, you can click  "Run now" to push the provided commands to the selected devices.

...

For details on exactly how commands are sent to devices, please see How commands are sent to devices.

...

Macros

Since version 2.0.3, Unimus supports command submission modifiers and sending control sequences.

There are 2 command submission modifiers possible:

$[enter]
$[no-enter]

These modifiers have to be put at the end of the line, and control if <Enter> will be sent after the command line.
The default behavior is to send <Enter> after each command line, UNLESS "$[no-enter]" is specified, or the command is a control sequence.
(please check the Command parsing examples section for more details)

NormallyRelease 2.4.0 introduced overhaul of how modifiers work.

To customize Mass Config Push Presets Unimus supports using of Macros. These are Modifiers, Actions and User variables.

Modifiers

Modifiers are two-word macros used to adjust the interaction behavior with the remote device. Normally, Unimus waits for some know known output (for example a prompt) after each sent command line (see see How commands are sent to devices for  for more info).There are 2 modifiers that can influence this behavior, with "$[wait]" being the default behavior.

$[wait]
$[no-wait]

Specifying "$[no-wait]Since version 2.4.0 modifiers are used in the following way:

• allowed modifiers: wait-echo, wait-reply, enter, fail-on-error
• format: $(modifier_name yes/no)
• must always be at the end of a line
• multiple consecutive modifiers are allowed
• a single modifier can only be declared once
• are followed by <Enter> unless "$(enter no)" is used

Modifier submission alternatives example:

$(wait-reply yes)
$(wait-reply no)

Specifying "$(wait-reply no)" will cause Unimus to instantly continue sending the next command line without waiting for any device outputs.

This can be useful when for example the device doesn't respond with any data after sending some command/line, and you want Unimus to continue sending data to the device.

(please check the the Command parsing examples section  section for more details)

Unimus supports sending various control sequences to the device, in this format:

...

Actions

Actions are two-word macros used to send control sequences and delays for interactions requiring pauses during execution.

Since version 2.4.0 actions are used in the following way:

• allowed actions: send, delay
• format: $(action_name value)
• send inputs a control sequence (it is not followed by <Enter> unless "$(enter yes)" is used)
• delay simply waits for a specified time (in ms)
• can be placed at any position in a line

Action submission example:

$(send 0x03)
$(delay 100)

As mentioned above, <Enter> is not by default sent after a control sequence by default, but this can be forced by appending "$[enter]" to the end of the line.
Full list of command sequences available in this article: VT100 Control / Command sequences.

(please check the Command parsing examples section for more details)

Both submission modifiers and command sequences support escaping by prefixing them with an additional "\":

\$[0x01]  (send 0x03)  = "$[0x01](send 0x03)" will be sent literally to the device(s), instead of a control sequence
\$[(enter] yes) = "$[(enter] yes)" will be sent literally to the device(s), instead of modifying command submission behavior

...

The main (and most important) portion of Config Push is sending the actual commands provided in the "Commands" set to the devices. To make this simple - you can provide the same sequence of commands and key-strokes to Unimus as you would when interacting with the device CLI, and Unimus will properly interact with the device as expected. To understand more in depth how Unimus interacts with a device, here is a (still very simplified) chart:

Image RemovedImage Added

Note 1:
Unimus will automatically answer "Y" to questions like "Show all items?" or "Do you want to show sensitive items?", etc.

...

commit
$[(send 0x1A])
y$[no-enter](enter no)

Device output (keys sent by Unimus in green):

...

banner motd ^$[no-wait]
(wait-reply no)
This is the start of the banner$[no-wait]
(wait-reply no)
And this is a 2nd line of the banner$[no-wait]
(wait-reply no)
This is the end of the banner^

It is important to NOT specify "$[no-wait](wait-reply no)" after the last line, since the device will respond with a prompt after the last line, and you want Unimus to wait for the prompt and collect the output.

...