Ugh - that's a horrible kludge way to make changes...
The dude could have so much potential ( I think reminds me a bit of the early HP Openview management tool circa 1994).
I use Zabbix for SNMP monitoring but keep a dude instance running on a CHR VM.
What can you do?
If you’d started off on the right foot and centralized remote control logically in a single location from the start,
there wouldn't have been any need to do anything, right?
That's true it's always easier to know where you should have started when you get to where you are going... but this didn't start out as 100+ routers, it started as an easy way for me to check out my PC support customer routers were up & working.
As a way going forward this isn't it... I can't even get a custom function returning /system resource uptime to work so going to look at other options, probably going for tr069.
Admiral is way out of the price range, Cloutic is possible but then updates are done by abusing the create a scheduled task process to create a script that is then executed as a scheduled task. At least TR069 is create a script & run it on the device.
I rather thought we were discussing a way to "get out of jail" here rather than an ongoing management system. I had the impression you wanted some way to enable SSH or API access on your current fleet that only has Winbox access, so you could then move to a more realised orchestration platform.
The dude could have so much potential
SO TRUE! Alas, many years of begging at the altar of Mikrotik Support has only produced several tantalising "feature wish lists" forum posts from Mikrotik Staff. We all wait with baited breath for the merest hint of a New Dude. Sadly these Latvian edge lords offer us not a scrap of relief.
Precisely...
The suggestion to use "The Dude" was intended to set up the necessary VPNs for accessing the routers and centralizing their control,
not for it to remain the ongoing management method.
It started with access via WinBox alone, but evolved into a VPN concentrator using various possible systems,
far beyond what "The Dude" could offer...
Yes that's a fair interpretation of it - and might still be a route to push out the solution.
Can someone clarify the correct ros_command syntax
is it ros_command("ros cli command") or ros_command(ipaddress,"ros cli command") or something else. I have seen examples using ros_command($device, "ros cli command") which I assume is 'the device it is running against'?
Basta leggere.
Suffice read.
I have set up a function called Test_command as:
ros_command("/system/resource get cpu")
(I may have initially entered ros_command("/system resource get cpu") but either syntax works on the device)
Then set up a probe called Test_command-p as:
Type : Function
Value : Test_command
I have then assigned that in services for the device.
I have entered the correct admin credentials in the device 'general' page
I get this in the logs on the target device:
(dude-ros-command/msg-proxy-7.24.4/tcp-ms
g(winbox):admin@10.55.11.5) bad parameter resource (line 1 column 22)
Along with repeated login failure for user admin from 10.55.11.5
via winbox messages - which don't change even if I use a different user in the device general settings...
Not directly through Winbox. But if your routers can make outbound connections, you can turn it around: let the routers pull the config instead of pushing it to them. You don't need SSH or API for this.
I run a scheduler on each router that downloads a script from a central HTTPS server and runs it:
/system script add name=pull-config policy=read,write,policy,test source={
/tool fetch url="https://your-server.example/mikrotik?apiToken=YOUR_TOKEN" \
dst-path=update.rsc check-certificate=yes mode=https
:delay 1s
/import file-name=update.rsc
}
/system scheduler add name=pull-config interval=1h on-event=pull-config
Going forward this might be worth a look at:
Well, there are no such packages so it is not a solution.