I have a linux perl script which use Net::SSH::Perl to connect and access MT boxes. The script works fine with 2.9.x , 3.x an 4.x ROSes. In the ROS 5.X there is something which causes the script is not able to login. Or if I change the SSH protocol version required to 1 the script is able to login but sending ssh commands fails.
Did anybody solve the problem already?
Just a note: the scripts uses Mikrotik API heavily (because it’s much faster than SSH access) but there are some commands which are not accessible via API.
What SSH commands are you actually using that have no API equivalents? It would probably be best to rewrite those with API syntax. Most single SSH commands can easily be rewritten as several API calls.
I need SSH to be able to enable API if it is disabled. This requirement is already obsolete probably these days (since fresh MT boxes have the API enabled and our ‘firsttime’ CFG enables it too)
the script uploads a generated CFG (a script which sets all the things) then using ‘/import’ it loads the CFG and then it watches some CLI script variable to see if the import has already finished (since on slow boards it can take several tens of seconds to complete) and whether it was successfull. I don’t know a direct way how to read a CLI variable using API (perhaps except running an extra script - which is a problem on slow old boards like RB133C3 which are in the time overloaded by the import) = equivalent of “:env print” or “:global $myvar; :put $myvar” …
I believe if you use the import command from API (and with a tag if you need other commands in the meantime), you’ll get the !done response only after the import is finished, so there’s not even a need to watch global variables only to see if importing is done.
If you must though, you can read (or even change) their values from “/system/script/environment”.
Also, instead of uploading a file, you can add an appropriate script at “/system/script” with the file’s contents as the script’s source, and then run the newly added script from API.
I can check this - I need to know when the import failed too.
good hint, thanks.
Yes I probably can. But the upgrade perl script uses scp to upload new ROS image so I simply used the same way to upload a new CFG…
And I already run some Mikrotik’s scripts during the update process and I had to run them using SSH because the scripts behave differently when they are started from API…
The problem with advices above is that now I have a mass upgrade script which works with all the ROS versions we have in our network (except the 5.X). And there are/were some workarounds for some versions of ROS (which behave differently). I would prefer to just have the old SSH working to not waste time by debugging the script again.
I can check this - I need to know when the import failed too.
With API, there are !trap responses for that, although I’m not sure if you’ll get one if only some of the commands in the import failed… if you want THAT with API, you’d have to convert the CFG to an API script instead or, as you’re already doing, set global variables for certain “sections” of the import, and verify them after the import.
But the upgrade perl script uses scp to upload new ROS image so I simply used the same way to upload a new CFG…
Oh… well… I don’t know of a way that part can be migrated to API… but is that part (the upload) at least working OK currently? If not, using FTP instead of SSH is probably going to be a better idea for cross version compatibility.
And there are/were some workarounds for some versions of ROS (which behave differently).
The very idea of the API is to reduce such inconsistencies down to the very commands, i.e. if the command and its arguments are the same across versions, the response will be readable properly across versions as well, since the protocol is frozen, and the output is sliced, unlike SSH, where MikroTik allow themselves to refresh the output (and thus break scripts relying on SSH) across major versions.
I have no problem with SCP it works fine even with ROS5.X (using Net::SCP::Expect). Only the Net::SSH::Perl causes problems.
And there are/were some workarounds for some versions of ROS (which behave differently).
The very idea of the API is to reduce such inconsistencies down to the very commands, i.e. if the command and its arguments are the same across versions, the response will be readable properly across versions as well, since the protocol is frozen, and the output is sliced, unlike SSH, where MikroTik allow themselves to refresh the output (and thus break scripts relying on SSH) across major versions.[/quote]
Currently my perl script uses a ‘wrapper’ functions for all remote actions - internally the action uses MT API if there is MT API active on remote box. If there is no MT API available the SSH is used. And there are exceptions where I got strange behavior via API and using of SSH solved the problems (running a /system/script and probably more).
I will try to forgot about SSH when I have MT API connection…