rss
Easily push development code
This makes team-development easier, by pushing patches very quick between our repos. In your .bashrc, insert this code, and adapt $REPO to fit your needs :
function push () {
REPO="dev.licorn.org:/home/groups/licorn.wmi2"
make darcs_record_prehook
darcs wh -l
echo -n "OK to record? ([additionnal record message] + [Enter] or Control-C to quit): "
read -e MESSAGE
if [ -n "${MESSAGE}" ]; then
darcs rec -a -m "Work in progress `date '+%Y-%m-%d %H:%M:%S'` (${MESSAGE})."
else
darcs rec -a -m "Work in progress `date '+%Y-%m-%d %H:%M:%S'`.";
fi
echo -n "OK to push? ([Enter] or Control-C to abort): "
read DUMMY
darcs push -a ${REPO}
}
Core-rewrite #1 + full-i18n, new inotifier work started
The past 2 weeks have featured a great core rewrite that I wanted to achieve for a long time. Core objects (Users, Groups & Profiles) are now clean objects, implemented with all the pythonic-fancyness that modern code can have (most notably properties, weak references and internal generators where applicable). Controllers manipulates them in a clean way too, doing things the CoreUnitObject can't do because they are not aware of the controller context (which make the whole thing totally logical, finally; things as they were meant to be, at last; [put your favorite self-satisfaction sentence here]).
Controllers and unit objects moderately use the daemon service facility, to make things more instant to clients and avoid long-activity stoppers: for example, setting permissive ON/OFF on groups launches a background check on shared data and returns instantly (among others).
As a consequence, the service facilities are initialized very early in the daemon (even before the LMC initializes) and are usable everywhere: Each individual object has a licord R/O property (named after this avoid collision with the Thread's daemon attribute), offering directly the {service,aclcheck,network}_* methods. The imports overhead and dirtiness of the previous implementation is totally avoided.
The patch lies in the development repository (not referenced in trac but accessible to SSHers). I will not push it to the stable branch until the new inotifier has landed, but it is very stable (testsuite has run many times on it).
The Full-i18n milestone will soon be closed (or nearly), because #2, #70, #541, #542 and #544 are implemented or closed in this patch. Thus, besides the full-object rewrite, we now have on-the-fly in-thread language transparent switching, and this really rocks for the WMI.
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.
