[Solved] Triggered backups and Unimus config mode access

[Dan S]

Hi all,

I've just started having a go at Unimus, enjoying it so far, but I have a question about what Unimus does when it's logging in during a discovery/backup.

My plan is to get devices to send a syslog message when their config is (potentially) updated, and using that to trigger an API request in Unimus to run a backup. This part is all fine and I have it working, however I've noticed that I get a "SYS-5-CONFIG_I: Configured from console" message from Cisco and an "exiting configuration mode" message from Juniper whenever the Unimus backup schedule runs or a device is discovered (but not when I just initiate a manual backup).

Can I check, is that normal behaviour, e.g. the discovery making sure its credentials work in config mode? I can work around it by ignoring the "configured by console" messages that are initiated from the server's IP, but I'm just curious about what's happening behind the scenes and under what circumstances config mode is entered.

Kind regards

Dan

[Tomas]

Can I check, is that normal behaviour, e.g. the discovery making sure its credentials work in config mode? I can work around it by ignoring the "configured by console" messages that are initiated from the server's IP, but I'm just curious about what's happening behind the scenes and under what circumstances config mode is entered.

Hi, this is indeed normal. During discovery, Unimus checks which modes are available with the discovered credentials. This is so Unimus always has up-to-date info on the device. For example, you might have Config Push presets scheduled which require enable/configure modes, so Unimus needs to know which devices support those.

More info is available in the Discovery article on the Wiki: https://wiki.unimus.net/display/UNPUB/Discovery

[Dan S]

Can I check, is that normal behaviour, e.g. the discovery making sure its credentials work in config mode? I can work around it by ignoring the "configured by console" messages that are initiated from the server's IP, but I'm just curious about what's happening behind the scenes and under what circumstances config mode is entered.

Hi, this is indeed normal. During discovery, Unimus checks which modes are available with the discovered credentials. This is so Unimus always has up-to-date info on the device. For example, you might have Config Push presets scheduled which require enable/configure modes, so Unimus needs to know which devices support those.

More info is available in the Discovery article on the Wiki: https://wiki.unimus.net/display/UNPUB/Discovery

Thanks very much Tomas, that answers all of my questions - can't believe I missed that page! The discover-during-backup-schedule approach makes sense for the reasons you've set out; I think I will bind credentials to my devices to reduce the chattiness of our syslog monitoring, which loves to tell me all about failed login attempts.

Kind regards

Dan

[toro]

Hi all,

I've just started having a go at Unimus, enjoying it so far, but I have a question about what Unimus does when it's logging in during a discovery/backup.

My plan is to get devices to send a syslog message when their config is (potentially) updated, and using that to trigger an API request in Unimus to run a backup. This part is all fine and I have it working, however I've noticed that I get a "SYS-5-CONFIG_I: Configured from console" message from Cisco and an "exiting configuration mode" message from Juniper whenever the Unimus backup schedule runs or a device is discovered (but not when I just initiate a manual backup).

Can I check, is that normal behaviour, e.g. the discovery making sure its credentials work in config mode? I can work around it by ignoring the "configured by console" messages that are initiated from the server's IP, but I'm just curious about what's happening behind the scenes and under what circumstances config mode is entered.

Kind regards

Dan

Hi May I ask how this solution is implemented?
Which logging server are you using, and what is your approach for executing or integrating the API?

[Tommy.c]

@toro

This can be done with NetXMS, or any NMS/Syslog listener that is capable of processing the received syslogs and running scripts based off the message contents.