The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My work

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,842 other followers

Archive for the ‘Development’ Category

Mikrotik Router OS 6.37.1 – scripts and schedules – what policies they need to run

Posted by jpluimers on 2017/10/19

minimum schedule and script policies: read/write/policy/test

minimum schedule and script policies: read/write/policy/test

A year later, Mikrotik still needs to update their documentation, so from my question at [WayBack[Mikrotik follow-up needed] Router OS 6.37.1 – scheduled script cannot execute script – MikroTik RouterOS.

TL;DR:

  • use the same policies for scripts and schedules
  • use these policies as a minimum for scripts and schedules:
    • read
    • write
    • policy
    • test

Forum post:

I found out two things:

  1. the testFunctionScript needs at least these policies to call a function: read, write, policy, test
  2. a schedule needs at least the same permissions as a script in order to run the script at all

This is how the various permissions affect the testFunctionScript script:

  • no policies only allow :log info "testFunctionScript"; .
  • read allows the above and :local testFunctionJobs [/system script job print as-value detail]; which then is be logged with :log info "testFunctionJobs=$testFunctionJobs";
  • only write seems equivalent to no policies as it will only allow :log info "testFunctionScript";
  • read and write is equivalent to read
  • a lone policy or test policy (talk about confusion!) do not add functionality, so any combinations of just policy or testwith read and/or write get the same functionality as above
  • policy and test without any other seem equivalent to no policies as they result in only :log info "testFunctionScript"; to execute
  • the combined policies read, write, policy, test allow full script functionality including the function call and using the function call result

The above findings show that more logging is needed: the scheduler should log when (and why!) it does not have enough permissions to run a script. Right now you’re in the dark on when (and why!) a script isn’t ran by the scheduler.

The above findings show that these parts of the documentation need updating:

http://wiki.mikrotik.com/wiki/Manual:Sc … repository (update with info about the above policy combinations)
http://wiki.mikrotik.com/wiki/Manual:Ro … Properties (update with info about the above policy combinations)
http://wiki.mikrotik.com/wiki/Manual:System/Scheduler (does not document anything about policies at all)

The various scripts (apply your mix of policies that you need)

## logon as user jeroenp

/system script environment remove [ /system script environment find where name="testFunction" ];
:global testFunction do={
  :local result [/system resource get uptime];
  :return $result;
}

/system script environment print detail where name=testFunction
# 0 name="testFunction" value=";(eval /system scheduler  (eval /localname=$result;value=(eval (eval /system resource getvalue-name=uptime))) (eval /returnvalue=$result))" 

:log info "direct execution of testFunction"

{
:global testFunction;
:local testFunctionType [:typeof testFunction];
:local testFunctionResult [$testFunction];
:log info "testFunctionScript";
:log info "testFunctionType=$testFunctionType";
:log info "testFunctionResult=$testFunctionResult";
:log info "testFunction=$testFunction";
}

/log print where buffer=memory && (message~"testFunction" || topics~"info")

/system script remove [ /system script find where name="testFunctionScript" ];
/system script add name=testFunctionScript owner=jeroenp policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":global testFunction;\r\
    \n:log info \"testFunctionScript\";\r\
    \n:local testFunctionType [:typeof testFunction];\r\
    \n:local testFunctionResult [\$testFunction];\r\
    \n:log info \"testFunctionType=\$testFunctionType\";\r\
    \n:log info \"testFunctionResult=\$testFunctionResult\";\r\
    \n:log info \"testFunction=\$testFunction\";\r\
    \n"

:log info "execution of testFunction via testFunctionScript"

/system script run testFunctionScript

/log print where buffer=memory && (message~"testFunction" || topics~"info")

/system scheduler remove [ /system scheduler find where name="testFunctionScriptSchedule" ];
/system scheduler add interval=10s name=testFunctionScriptSchedule on-event=testFunctionScript policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=sep/22/2015 start-time=12:02:37

:log info "execution of testFunction via testFunctionScriptSchedule calling testFunctionScript"
:delay 20s
/system scheduler disable testFunctionScriptSchedule

/log print where buffer=memory && (message~"testFunction" || topics~"info")

/system scheduler print detail where name="testFunctionScriptSchedule"

–jeroen

Posted in Development, Internet, MikroTik, Power User, RouterOS, Routers, Scripting, Software Development | Leave a Comment »

delphi – VCL events with anonymous methods – what do you think about this implementation? – Stack Overflow

Posted by jpluimers on 2017/10/19

A long time ago, Pablo Vizcay a.k.a. [WayBackpragmatic_programmer wrote some cool code at [WayBackdelphi – VCL events with anonymous methods – what do you think about this implementation? – Stack Overflow.

I still think it’s a very neat solution to bind method references to events.

type
  TNotifyEventDispatcher = class(TComponent)
  protected
    FClosure: TProc<TObject>;

    procedure OnNotifyEvent(Sender: TObject);
  public
    class function Create(Owner: TComponent; Closure: TProc<TObject>): TNotifyEvent; overload;

    function Attach(Closure: TProc<TObject>): TNotifyEvent;
  end;

implementation

class function TNotifyEventDispatcher.Create(Owner: TComponent; Closure: TProc<TObject>): TNotifyEvent;
begin
  Result := TNotifyEventDispatcher.Create(Owner).Attach(Closure)
end;

function TNotifyEventDispatcher.Attach(Closure: TProc<TObject>): TNotifyEvent;
begin
  FClosure := Closure;
  Result := Self.OnNotifyEvent
end;

procedure TNotifyEventDispatcher.OnNotifyEvent(Sender: TObject);
begin
  if Assigned(FClosure) then
    FClosure(Sender)
end;

end.

And this is how it’s used for example:

procedure TForm1.FormCreate(Sender: TObject);
begin    
  Button1.OnClick := TNotifyEventDispatcher.Create(Self,
    procedure (Sender: TObject)
    begin
      Self.Caption := 'DONE!'
    end)
end;

–jeroen

Posted in Delphi, Delphi 10 Seattle, Delphi 10.1 Berlin (BigBen), Delphi XE, Delphi XE2, Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development | 1 Comment »

Kristian Köhntopp – Google+

Posted by jpluimers on 2017/10/18

[WayBack] Kristian Köhntopp – Google+:

The S in IoT is for Security, and the U is for Update Policy.
 –jeroen

 

Posted in Development, Fun, Power User, Quotes, Software Development, WiFi | Leave a Comment »

The Software Development Process – Science, Engineering, Art, or Craft? – CodeProject

Posted by jpluimers on 2017/10/18

On the long-read list: [WayBackThe Software Development Process – Science, Engineering, Art, or Craft? – CodeProject

 

Posted in Software Development, Development, Agile | Leave a Comment »

GitHub – sinbad/spriterecolour: Sprite processor to allow dynamic recolouring

Posted by jpluimers on 2017/10/18

One day this will be extremely useful to me: [WayBackGitHub – sinbad/spriterecolour: Sprite processor to allow dynamic recolouring

Via: [WayBackSpriteRecolour, an open source sprite recolouring tool · SteveStreeting.com

TL;DR:

Read the rest of this entry »

Posted in Algorithms, Development, Software Development | Leave a Comment »

 
%d bloggers like this: