Recently i am working on a updating script in RouterOS
and i used this command:
/update/check-for-updates
I found this command require read+write+policy to work ,which confused me:
Read: it’s ok
Write: I think it shouldn’t be needed because it’s just checking for updates…
Policy: the official document said
policy - policy that grants user management rights.
but — i was just trying to check-for-update, why does this command need “policy” right to work properly? —i dont know ,can anyone tell it? thanks much.
Likely the explanation is that the entire /system/package/update has been set to the same rights requirements.
I.e. it is silently assumed that after checking for updates and finding that an update is available, you probably want to download and install it anyway.
When you only want to check and maybe send a mail alert, indeed that is not correct.
Thank you for your warm replying !
I’d like to download and install the update pack later but i stopped when i met and tried to solve this permission problem
I don't think user rights management is ever relevant when I'm working on /system/package/update.
RouterOS policy system is very confusing and ancient in my opinion. Mostly confusing and misleading. Instead of having a documented matrix of permissions for each command/section, you get a vague list of policies with some examples where these policies may apply. It is frustrating monkey work to find the correct minimal permissions needed for scripts. So many people probably run their scripts with "dont-require-permissions=yes" and forget about it.
Well, of course you need write permissions and probably also reboot permissions to be able to upgrade the firmware. So in the end your script will require that, and in most cases it would not be a limitation when “check for updates” also requires that.
I have a script that does read the /system/package/update/get value-name=latest-version and needs "ready" policy. The script also has ftp policy. because it uses /tool/fetch to download npk packages.
So I would not say it is most times the intention to perform updates, when scripting in the package section.
Is "fetch" a policy? (should be "test" that allows fetch tool)
Coincidentally I am trying to put together a "cheatsheet" for policies, at the moment nothing of practical use, but I have assembled this "general scheme":
This said, what I personally do is to give to a script all permissions (minus the obvioously unrelated ones) then remove one by one until it stops running, and then re-add the last removed one, it is a 4-5, maybe 6 steps procedure and definitely far from elegant, but it is not that bad after all.
Well, another confusing setting.
According to the (scarce) documentation to use the "fetch" tool you need the "test" policy, "ftp" policy should be for - well - ftp.
Did trial and error today. Made sure to use /script/run foo use-script-permissions. Turned out, my script needs the following policy to work: policy=ftp,read,write,test. Removing any of these, breaks the script by either not enough permissions (9) or failure: cannot open file: permission denied. And my script uses these system command:
/system package get value-name=version routeros
/system package update check
/system package update get value-name=latest-version
I don’t feel motivated to try this again. Getting to that point was already quite painful.
In my opinion, MikroTik should consider deprecating this policy system and replacing it with something more practical. Ideally, this should be addressed in v7 rather than postponed to a future major release.
At least it seems that MikroTik is aware that the current policy system has significant shortcomings.
I think it would be enough a simple table with a list of all commands and which policy is needed for each to be working.
In other words proper documentation.
Yes, they should use a standard logging function that in case of permission problems also adds the required- and available permissions for that command. That would be guaranteed to be up-to-date (as opposed to that info being put in the documentation, where it may be wrong or out-of-date).
In general, log messages in RouterOS could benefit from more identifying information. There often is a text and an error code, but much more rarely there is an actual mention of the object that causes the problem (like MAC address, IP address, filename, …).
MikroTik is not very consistent in keeping their documentation up to date. In some cases, they publish documentation for settings that are only available in development builds. In other cases, features that were introduced or changed two major versions ago are still not properly documented.
For this reason, the software itself should provide clear, accurate, and meaningful log messages that users can understand and rely on when troubleshooting or configuring the system.
Sure, that would help, but it remains a "try and see what happens" approach, not entirely unlike my "brute-force" approach, only slightly better.
Still, once upon a time, but recently enough that I can actually remember the procedure, computers were not ubiquitous, there was actually only one in a whole university, you had to write programs on paper, run and debug them in your mind, following the syntax and documentation, then (painstakingly) convert them to punched cards, then book some 15 minutes (30 if you were lucky) of the computer time (like next tuesday from 15:30 to 15:45) manuallly feed the cards under the critical eyes of the department technician, and finally see if it would do what was expected.
A single, teeny-tiny mistake (in either the program or the card punching) would mean "see you next week".
In punch hole cards time none of today's software would survive. The mentality of shipping fast and fixing by providing patches every few days is burned into brains of today's software companies.
—i dont know ,can anyone tell it? thanks much.
