Posts in category network

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.

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.

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.

Removed silly limitations on system groups with LDAP backend enabled

Responding to changeset 279 and explaining the reasons of changeset 304, there is now no more limitations when creating system groups.

If the LDAP backend is enabled, the newly created system group will go into the LDAP backend.

This makes NFS works perfectly on LDAP-enabled clients, which now see all groups when listings ACLs and standard posix perms.

Now, the licorn-ldap-server debian package tries to move every important pre-existing system group (acl, licorn-wmi) from the Unix backend to the LDAP one. This will implicitly install them network-wide and avoid the need to create them on every ALT®. Finally this will help propagate admin privileges on every client.