search

labscript-suite-temp-2 / blacs

BLACS, part of the labscript suite, provides an interface to hardware used to control a buffered experiment. It manages a queue of shots to be run as well as providing manual control over devices between shots.
Other
0 stars 0 forks source link

Remote control #24

Open philipstarkey opened 7 years ago

philipstarkey commented 7 years ago

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

In our lab we have extended the BLACS server to allow other programs (like our watch dog) to pause the queue.

I can think of other things that could be done with this. The runmanager abort button could be connected with a command clearing shots already loaded into BLACS. As aborting compilation usually goes hand in hand with this action anyway.

Is this something that is useful to others? If so I would write up a pull request.

philipstarkey commented 7 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

I'm not sure it would be useful for our lab, but that, but that doesn't mean it won't be useful to others. Perhaps it could be implemented as a plugin for blacs/runmanager?

@shjohnst has written a plugin (in our krb fork of BLACS) which pauses the queue (the plugin monitors conditions reported from process control systems in our labs, which are logged to syslog and then forwarded to BLACS over ZMQ), so you could look to that for inspiration. I would suggest paying attention to security as well, so that rouge people on a network can't unduly affect BLACS (right now they can only submit shots, and such shots must match the connection table, so its semi-safe)

philipstarkey commented 7 years ago

Original comment by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

FYI Our labwatch plugin is here: https://bitbucket-archive-test.labscriptsuite.org/#!/monashkrb/blacs/commits/branch/labwatch_plugin

Note that it is incomplete (the gui for adding devices to watch is only just functional) but I plan on finishing this off, as well as adding documentation, once we've sorted out the issue of the best way to share non-core plugins, devices and other "add-ons" for the suite.

philipstarkey commented 7 years ago

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

I'll have a look at your plugin and see if I can maybe adjust my watchdog to work with it.

The security thing is a good point I didn't think about, as we have the whole lab running isolated from the rest of the network.

philipstarkey commented 7 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

FYI it looks like you can access the entire queue from the notification class plugin (see here). You probably don't want a notification, but maybe you can use it without actually having something visible (at the very least, you could have a dummy notification that is not visible). Probably not ideal, but at least keeps the code segregated for now. The plugin API (including what is exposed through the BLACS dictionary I linked to above) is very much experimental, and as such you should feel free to expose more things through the API if you need them!

We'll hopefully sort something out regarding maintaining plugins (there's a discussion about this somewhere...can't find it now!) so stick your new plugin in a branch of BLACS for now and we'll sort out the best way to turn it into a pull request :)

philipstarkey commented 7 years ago

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

All that security stuff got me thinking is runmanager secure? As it spawns a child process which executes code that it is given it would really be bad if not. Are there any checks in place to ensure that messages from the network won't be accepted or similar? I'm not all to familiar with the workings of zprocess @chrisjbillington do you have a quick answer to this?

philipstarkey commented 7 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

Runmanager currently doesn't accept remote commands of any sort. It executes arbitrary code that the person operating it tells it to, yes, but so does the Python interpreter, or any IDE, so that's nothing unusual.

I'm in the process of adding preshared key security to zprocess, which will make things properly secure, although at the moment there are already risks due to programs unpickling data from each other, and unpickling untrusted data is unsafe. So labscript programs should already not be run on untrusted networks, though once I get the preshared key stuff in it will be fine to run it anywhere.