Posts in category licorn

dev.licorn.org migrated to a dedicated server, Licorn® project using Git and GitFlow

After some years of mutualized hosting, dev.licorn.org is now living on its own on a brand new Ubuntu 12.04 LTS server. It lives in a dedicated LXC container; the hosting machine is fully dedicated to the Licorn® project, running docs.licorn.org in another LXC, and many more things I wanted the project to have (a build machine, etc).

Meanwhile, we have switched from darcs to git. Having encountered the  fatal #1520 bug has urged us to do so, because this bug just prevents us from working. But it's really the tip of the iceberg, because I wanted to switch to Git for a long time.

Even better, we now officially use  GitFlow to follow the famous  successful Git branching model, and I'm very happy with this clean approach.

Things will only go better now ;-)

Documentation updates (modules states, small reorganization)

I've just updated the Licorn® documentation:

My Darcs boring file

This file contains filenames that darcs should not care about. So here we go (only the relevant part), in _darcs/prefs/boring on every of your repos: 

^tests/data/scenarii
^tests/data/\..*_status
^tests/data/\.owner
^tests/data/wmitest

docs/_build
^locale/fr
^interfaces/wmi/.*_donnut.png
^interfaces/wmi/js/json

\.pye$
^tailoritself\.
\.mo$

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.

Daemon status available

In my last patch I added the availability to query daemon status, in two ways:

  • the get status command, which can be called with argument --full. This command is complemented by get users --dump, get groups --dump and so on, which help debugging daemon internal data structures without stopping it. This method for getting the daemon status is independent from its state (forked into background or not).
  • when the daemon is attached to the terminal (launched with -D), you can now type uni-letters commands to query it:
    • 'f' or 'l' will toggle between normal and full status.
    • [Enter] will just display a newline (usefull for manually marking spaces between different operations.
    • Ctrl-L will clear the screen, like in a normal terminal.
    • Ctrl-T will display the current status of the daemon (full status depends on wether you activated it before or not, beiing disabled by default and remembered across the daemon session when you set it, until terminate or restart).
    • Ctrl-Y (or space) will do the same, but will clear the same first. Typing repeatedly on space will emulate a top-like behaviour, permitting to monitor the daemon status, even if it is very active.
    • Ctrl-R will reload the daemon (by sending it an USR1 signal). Very useful when you modified daemon or core code, just hit R in your daemon terminal and you're done with the new code reloaded.
    • Ctrl-C will break and terminate, as expected.
    • Ctrl-U will terminate the daemon with a traditionnal signal 15 (similating a normal kill or killall).
    • (Caution) Ctrl-K will send a real KILL signal, when the daemon is stuck.

In some rare cases (when the interactor thread is crashed, which never happens ;-) ), you will not be able to use these commands and will need to operate "à l'ancienne" (Ctrl-Z, bg, sudo killall -r licornd and al.).