I just wrote a short script to refresh the SMTP server IP address from its FQDN (since routerOS won’t access anything except an @IP…), and see something strange: script policy is “read,test”, but it still can change email server setup when run directly from CLI…
name="script-SMTPrefresh" owner="elgo" policy=read,test last-started=mar/20/2012 12:56:12 run-count=4
source=
# refresh SMTP server address used for email notifications
# because email parameter can't be a FQDN but only an IP address
:local smtp [:resolve ("smtp.gmail.com")]
/tool e-mail set address=$smtp
:log info ("SMTP server updated: ".$smtp)
Why is this script behaving like it has “write” policy applied? Are script policies even effective?
Now, another question: what does a scheduler policy mean? Why would it be different from the script it runs?
Maybe it’s because it needs to “write” a value into the smtp variable.
The only policies that I really use are “reboot” and “sensitive”, the later to hide it from exports if the contain any kind of sensitive data like passwords, local IP’s or whatever.
I may have not been really clear: my script should need the “write” policy (it changes a parameter value), but it hasn’t, and still behave like it has it (since the value is finally changed).
OK, so as far as I can see, nobody uses “scheduler policy” or “script policy” features, because, let’s try to guess, it’s not working the way it’s supposed to be? Because as it’s not a widely used feature, so as it usually happens in MT world, regressions aren’t detected before long and nobody cares fixing them before even longer?
I know it’s “only” supposed to be a security feature, but still, I don’t get it.
Somehow it reminds me of the “VLAN-MODE” switch chip feature that you “should” set to “fallback” and not “secure” or… you’ll get serious issues.