rss
First official extension: openssh
Tonight I sprint-coded the OpenSSH extension, removed all openssh-related code in LMC.configuration, and added system-service-related code to SystemController class.
Guess what:
- It works like a charm :-)
- I readded the missing functionnalities from previous releases (the AllowGroups configuration directive), and added much more (enable/disable ssh extension and service, check other configuration directives, verify the sshd is running...)
By the way, members of remotessh are allowed to connect, and members of admins too (regardless of their remotessh member status: this is cool because you (the reader) are probably already a member of admins, and you won't ever notice the sshd group-authorization enforcement ;-)
The OpensshExtension module can serve as an extension model: it seems quite clean (and short) to me.
This work would not have been so easy without the ConfigFile class Robin wrote. I enhanced it a little, but it's so practical!!
Modules (backends and extensions) renamed, better handling
To avoid conflict with eventual future backends and to stick a little more with reality, the unix backend has been renamed to shadow, and the ldap backend has been renamed to openldap. They are held in files shadow.py and openldap.py in the ShadowBackend and OpenldapBackend classes. Much readable, isn't it?
Configuration, testsuite, documentation website are up-to-date with this change.
Module loading is now much more clean: the backends and extensions do not need to be instanciated in their python file anymore, this is taken care by the manager. This makes code much understandable (I hope), shorter, and more standard. Sphinx autodoc can now be used on backends classes too, whereas it wasn't possible before.
core.backends.classes has dissapeared (the related code is now directly inside core.backends.__init__), and idem for extensions.classes (now in extensions.__init__).
So, The python modules filenames and controller classes names changed, and are shorter: e.g. dnsmasq.py holds the DnsmasqBackend (instead of dnsmasq_backend.py containing dnsmasq_controller), and so on. This rule applies for backends and extensions.
Small other renames have landed too, like ModuleManager having becomed ModulesManager and other minor changes.
Network discovery in the daemon
The daemon has now an auto-discovery capability on its local network(s). It will scan the LAN (on all of its ethernet interfaces) and will try to discover all hosts which are up (answer ping).
With 10 to 30 network threads in each pool (the default beiing 5, is resource-conservative), it can be faster than nmap to do a full LAN discovery (you will gain ARP resolution and Pyro resolution bonuses).
You can disable the feature if you don't like it or experiment problems with it (don't forget to report bugs in this case).
We finally got rid of nmap and all those consuming subprocess.Popen calls, with a big functionnality gain.
User checks customization
Thanks to Robin who did all the hard work, chk can now be customized for users. This allow to avoid ACLs for a certain file hierarchy, or force some custom ones on another. For instance, I use these, in my ~/.licorn/check.conf:
source NOACL build NOACL Projects NOACL
This allow debian tools not to crash when building packages or scanning source trees.
There is a little loss in performances, but the win is clear compared to before. We will optimize the code on next performance run (there is a dedicated ticket for that).
System ACLs rules can be fully customized (with only a few sane exceptions) by administrators. For more details, there's a bunch of related documentation!
Documentation site is up
We set up a new site dedicated to Licorn® documentation, growing quickly as we link existing docstrings to it.
Some existing doc from the Trac has already migrated there, and brand new doc will be written, related to profiles management, group memberships, data sharing models between members of a same group, and the like.
Configuration files and directives will be documented there, too.
See you there, keep up bringing peace to the Earth.
Licornd is now fully interactive
You can debug licornd in a live interactive session. Just start it in the foreground (licornd -D), and press 'i' . You can access every object and do whatever you want (trigger a method, dump an object, really whatever the python language allows you ; so be carefull, you're root...).
Bonus: everything is auto-completed with <TAB>, like any interactive shell can be, and your command history is saved to ~/.licorn/licornd_history (thanks to readline).
Press Control-D when you are done to leave interactive mode and return to standard command mode.
The interactive session is implemented in a separate thread. The licorn daemon stays fully functionnal during it. Stopping and restarting individual things manually will probably come in the near future, but as of now if your display gets corrupted with other daemon output, just hit Control-L to clear your screen.
Example session:
olive@desktop-001 ~/licorn @ licornd -D
* [2010/04/12 01:01:44.8412] licornd/master@server(5124): starting all threads.
* [2010/04/12 01:01:44.8454] licornd/wmi(5129): started, waiting for master to become ready.
* [2010/04/12 01:01:44.9980] licornd/master@server(5124): all threads started, going to sleep waiting for signals.
* [2010/04/12 01:01:45.4224] licornd/wmi(5129): ready to answer requests at address http://localhost:3356/.
* [2010/04/12 01:01:47.6714] Entering interactive mode. Welcome into licornd's arcanes…
Licorn® @DEVEL@, Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2
licornd> LMC.users.keys()
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 13, 33, 34, 38, 39, 41, 300, 113, 100, 101, 102, 103, 1000, 105, 106, 107, 108, 109, 110, 111, 112, 104, 114, 115, 116, 117, 65534]
licornd> dqueues
{'pyrosys': <Queue.Queue instance at 0x9c7a18c>, 'reverse_dns': <Queue.Queue instance at 0x9c7a04c>, 'arppings': <Queue.Queue instance at 0x9c71eec>, 'pings': <Queue.Queue instance at 0x9c71dac>}
licornd>
* [2010/04/12 01:02:24.0383] Leaving interactive mode. Welcome back to Real World™.
* [2010/04/12 01:02:25.3743] licornd/master@server: signal 2 received, shutting down…
* [2010/04/12 01:02:25.3748] licornd/wmi: signal 15 received, shutting down…
* [2010/04/12 01:02:25.3751] licornd/wmi: exiting.
* [2010/04/12 01:02:25.5468] licornd/master@server: exiting (up 40 secs).
PS: i really love Python. These kind of things are just amazing.
PS2: the implementation can be incomplete, I didn't really test every object. Just report any bug you find and I will fix it ASAP.
Better trace customization
Starting from now, ltrace understands binary exclusions. You can debug the daemon and CLI tools with better cherry-picking of trace messages:
export LICORN_TRACE='core^configuration^groups' sudo python /usr/sbin/licornd -vD
This will trace everything in the core, except configuration and groups messages.
Binary inclusions still work, and you can combine the two:
export LICORN_TRACE='foundations^base^objects|core^configuration^groups' sudo python /usr/sbin/licornd -vD
Which will debug same level of core, but added foundations, without base and objects modules (which are very verbose and very low-level).
NOTE: the order matters when you write components name in the variable:
- you can write 'core^users^configuration', it will work because users and configuration are subparts of core.
- 'configuration^users' will display configuration messages only (users is not a subpart of configuration, nothing more is excluded).
- 'foundations|core^base^users' will work as expected.
- 'foundations^users|core^base' will not substract users from core, because core is processed later by the ltrace parser. base will be substracted from foundations, though.
