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.
LDAP-backend v1 commited
The first version of LDAP backend is out, numbered Licorn 1.2. On a freshly installed Lucid with an empty slapd, Licorn® will do everything needed to get a fully usable LDAP system (pam-ldap and nss-ldap wise).
Just run the following command:
sudo aptitude install licorn-ldap
And let the magic begins. What it does, summed up:
- install slapd, lib*-ldap and all licorn.
- wait for slapd to be started with the bare minimum configuration.
- setup all the rest of the slapd configuration (chk config -avb; read the gory details on the LDAP backend page).
- enable the LDAP backend on the whole system (mod config -b ldap), including lib*-ldap.
PAM setup should be done by the debian packages, which is the case nowadays on Lucid.
To be sure the LDAP module is available and enabled, just ask:
sudo get config backends
And the system should tell you:
ldap* unix
Everything else is just transparent: you can use Licorn® CLI tools as usual.
There is still work to be done, but it concerns new features only; the LDAP backend is currently feature complete, regarding users and groups.
LDAP configuration taking more time than the backend
I didn't expect that, but new configuration system (cn=config) in slapd and differences in distribution version (karmik and Lucid) prevented me to complete the auto-configuration for LDAP backend (autoconfiguration can be tricky if you want to make it right).
As of now the 'pure backend' (users and groups management) works perfectly over LDAP, provided that you manually setup the slapd frontend ("o" and different "ou"'s). You can find out every detail on the LDAPBackend wiki page. There is more information than you need, because the wiki page expects that you start from a Karmak setup (totally empty), whereas in Lucid the module and backend parts of slapd are already present.
Samba part is not yet implemented, but will come later. It needs several things to be worked out before.
Quality improving slowly...
As I primarily code new features and bugfixes, I tend to do QA changes when I can. This makes the global code quality improve slowly:
olive@Gany ~/licorn @ find . -type f -name '*.py' | xargs pylint [...] Global evaluation ----------------- Your code has been rated at 3.75/10 (previous run: -1.90/10)
Locally, the quality can be much better. There are files where I spent time to experiment with pylint remarks, and this shows:
pylint core/internals/users.py [...] Global evaluation ----------------- Your code has been rated at 8.32/10 (previous run: 8.17/10)
And files where I already modified some portions of code, but not all (since I don't have time):
pylint core/internals/configuration.py [...] Global evaluation ----------------- Your code has been rated at 6.01/10 (previous run: 3.19/10)
Anyway, major QA work will occur: we have a dedicated milestone for this !
WMI released, LDAP in progress
I released the version 1.1 of Licorn®, which is quite a good news. The first release after nearly a year of silence and 2 weeks of code.
All WMI features are completely functionnal, except the "import users" one, which is not critical in early deployments.
LDAP work has begun and I plan to release the first beta version (managing users and groups) between the middle and the end of the week. LDAP support will be very preliminary: we will support only all *nix features, not the SAMBA ones. But ongoing work will take care of extending these.
First goal is to make Linux clients authenticate against a Licorn® server, making the whole thing rock solid. I hate bugs ;-)
