Posts in category configuration

New experimental.enabled directive

There's a new experimental.enabled directive available in /etc/licorn/licornd.conf (no command line argument equivalent), which defaults to False if unset in configuration file. This flag will be used from time to time, to test experimental functionnalities in stable branch. Currently this enables the Machines tab in WMI, if you manually set it to True in your local configuration file (which I recommend if you're a developper or an advanced system admin).

WMI listen address is now configurable

The WMI listen address is now configurable, either:

  • in the main configuration file (/etc/licorn/licorn.conf if you didn't change it), with the directive daemon.wmi.listen_address. Don't put any quotes around the address. Example: 
    daemon.wmi.listen_address = 192.168.1.1
  • on the command line, when manually starting the daemon. Example: 
    sudo licornd -vvD -W 192.168.1.1

You can use an IP address, or a hostname (it will be resolved to an IP address). Note that the CLI argument has always precedence over the configuration file, for obvious reasons of easy testing.

New set of commands for privileges

If you know about privileges, you know you can manipulate them only via the configuration object, like this: 

get config privs
sudo add group licorn-wmi --system
sudo mod config --add-privileges licorn-wmi
sudo add group remote-ssh --system
sudo mod config --add-privileges remotessh
sudo mod config --del-privileges licorn-wmi,remotessh
get config privileges

Now you can handle them kind of "directly", like this: 

get privs
sudo add group licorn-wmi --system
sudo add priv licorn-wmi
sudo add group remote-ssh --system
sudo add priv remotessh
sudo del privs licorn-wmi,remotessh
get privileges

Which is quite simpler, and - I think - more logical or consistent with the rest of the command set. The code lies in changeset 310.

Two small changes worth noticing in add user/group

two points which were pushed in revision 279, because bzr don't know anything about cherry picking (or I don't know how to use it):

  • system users/groups are now always created in the Unix backend. this is far from perfect because they have to be replicated for ACLs to work and this will NEED to be done for the cluster, but the cluster doesn't exist yet, so don't bother. This is needed for groups like acl, remotessh and admins, which NEED to be created in /etc/group on the local system before the LDAP backend is activated (they are checked/created before the LDAP setup). This is kind of a workaround because it should work event with these groups in LDAP, but this implies some deep reorganization in the LicornConfiguration class, which will be done later (see #170).
  • add a --force argument to add user/group, for the particular case of user/group with same name. This was trigerring a bug on old debian/ubuntu systems, but should be bypassable nowadays, because I expect adduser tools to have been fixed on this particular point.