On Tue, 28 Aug 2018 at 19:49, Kevin Hilman khilman@baylibre.com wrote:
On Tue, Aug 28, 2018 at 12:41 AM Neil Williams neil.williams@linaro.org wrote:
On Tue, 21 Aug 2018 at 22:46, Kevin Hilman khilman@baylibre.com wrote:
Hello,
When trying to use lavacli to add a remote worker, it works fine if the user is a superuser.
Adding remote workers to an instance would be an easy way to DDOS an
instance by swamping the ZMQ ports with fake attempts - the process needs to be under the control of the admins of the instance.
If the remote worker is properly configured, it will register itself
automatically - this is why encryption of the master:slave communication is so important. A LAVA master which is visible to the internet should always use encryption.
All masters and slaves are in control of the admins and encryption is enabled. The per-user permissions still do not work.
However, all of this still begs the question: why do those per-user permissions even exist if they don't do anything because superuser privileges are required? If that's a hard requirement, shouldn't those permissions just be removed so it's not confusing for admins?
In most cases, the lavacli workers add command isn't required.
Ahh... so, IIUC, when a new worker connects, it automatically adds itself. so a "workers add" command isn't needed?
Yes - with an up to date lava-master, (2018.5 and later IIRC, possibly a release or two earlier, I'd have to check) , the process is automatic.
What are the cases where a "workers add" is actually needed then?
lavacli needs to cope with older versions of lava-master.
We can update the manpage and --help output of lavacli - will also check to see if the XMLRPC call itself should become a no-op in the next release.
https://projects.linaro.org/browse/LAVA-1404