rss
Remote Interactive Console
Yes. Finally, this long-awaited feature is here: you can now attach to an already-forked daemon, and type commands inside it, remotely. Just enter get in (from "get inside") on your prefered CLI prompt.
I have been thinking about this remote debugger for a while. Crunching rlcompleter, readline and a derived InteractiveConsole in my head for days, It seemed really feasible and nearly easy, but I still missed a key to write it. I wasn't far from the result, which I found nearly complete in the rfoo python package.
Reading rfoo code inspired to me the #645, because it seems to have everything we need, while beeing much more shorter code-wise, and perhaps much faster than Pyro: the hard part of rfoo is implemented in C (via Cython). When performance problem arise in the cluster, I think we *will* have to switch to rfoo.
The easy part of the switch is that rfoo is "call compatible" with Pyro (both are completely transparent to python programs). Only the PyroProxyWithAttr cannot be implemented in rfoo, which seems wise enough from the security standpoint (everything in Licorn® will be reimplemented via methods to fullfit the security decorators, anyway).
All I have implemented ahead of Pyro seems to be re-usable "out-of-the-box" with rfoo, which makes me think the security decorators I'm thinking about will be, too.
On the road, while reading and derivating rconsole code for Licorn®, I found the fix for #582. I will surely offer myself a beer, or perhaps my collegues will offer it to me, If they read this. But the persons who really owe a beer are the rfoo developpers.
A big "thank you" to them. They saved me a great time, and showed me how to fix one the most obscure bugs.
NOTE: as a consequence, the local interactive console has vanished from the daemon. We can still interact with it, but this is becoming more and more useless, as much more things are available remotely (get status, get events, get inside), and usable more than once, in parallel, with different options.
Testing client/server communication
Defining LICORN_SERVER environment variable (in latest stable code) provides an easy way to test bi-directionnal communication between 2 or more Licorn® daemons installed on distinct machines.
WARNING: this is meant for testing and development purposes only. In production environments, there should be a DHCP server on the Licorn® machine with the SERVER role, and the CLIENTs will discover it automatically.
To use:
- be sure all machines are on the same IP network.
- set up one of the machine with licornd.role = SERVER in /etc/licorn/licorn.conf.
- find the IP address of this machine and remember it.
- set up all other machines with licornd.role = CLIENT
- open a Terminal on each, and run export LICORN_SERVER=<IP_address> with the IP address of your server.
- start all licornd, ending with the server one (else it won't detect the clients because they currently don't push their status to the server).
- alternatively, if you want to force detection of new clients started after the server, you can run add machines --discover <IP_subnet/mask> on the server, it will scan the subnet and register all new machines.
Besides this, be sure to set experimental.enabled = True on the SERVER machine, to get the Machines tab in the WMI.
You can now enjoy remotely shutting down client machines.
Pyro changes in stable branch
Pyro work has been commited to the stable branch. News:
- you don't need to use sudo anymore with licorn commands. If you're a member of group admins, everything should be transparent for you.
- every CLI tool and the WMI needs the daemon to work.
- CLI tools will launch the daemon if needed and wait for it to be ready before continuing.
Functionnaly-wise, nothing should have changed (this is guaranteed by the testsuite).
Security-wise, core objects are not yet protected with locks, but this is the next work to do in turn. For everyday use, this should not hurt (i've tryed to crash it, but didn't succeed).
