LCFG Client Refactor: Further node name support

I remember once as a 12 year old playing rugby at school. I received the ball, saw the field ahead was clear and knew that this was the time to run like hell. For one joyous moment I was brushing aside the defending team, spotting my moment of glory, having never been a particularly sporty kid was this my chance to join the cool crowd? Sadly, someone burst my bubble and pointed out that the main reason I wasn’t being flattened was because we were actually playing touch rugby…

Anyway, my general point is, it’s always good to know when, having been passed the ball, you should just run like hell and see what happens. It might also be good to remember which game you are playing but, hey, ho…

Having been given the chance to split the LCFG node name from the host name, I spotted a chance to really make it count. In short order the following code has been altered to extend this support to the whole of the LCFG client framework:

  • perl-LCFG-Utils 1.5.0
  • lcfg-ngeneric 1.4.0
  • lcfg-om 0.8.0
  • lcfg-file 1.2.0
  • lcfg-authorize 1.1.0
  • lcfg-hackparts 0.103.0
  • lcfg-logserver 1.4.0
  • lcfg-sysinfo 1.3.0
  • lcfg-installroot 0.103.0

None of this has (yet) been shipped to the stable tree since it needs more hacking of the current LCFG client (v2) code to fix a compatibility issue.

The big achievement here is that it makes it possible to specify the lcfg nodename on the PXE installer kernel command-line via the lcfg.node parameter and get the whole way through to an installed managed machine which is using a LCFG profile which is completely unrelated to the host name.

There are various big benefits to this change. It is now possible to have a fully roaming machine which is LCFG managed, there is no requirement for a static host name or static IP address. This means that no matter what host name or domain name settings are in place the LCFG client will continue to work as required. This also makes it possible to use a single “generic” profile to configure multiple machines. If you know you have a lab full of identical machines this could be very handy indeed.

The downside of this is that some things like spanning maps will not work the way you might expect. You also will not receive notifications from the server when a profile changes, you have to really solely on the poll time (probably worth making the timeout shorter). You probably also cannot send acknowledgements to the server and the LCFG status pages will consequently be mostly useless for those clients. It is also difficult to configure networking to do anything other than use DHCP. You’re choosing to move some of the configuration information back out of LCFG (or at least out of a particular profile). You may end up saving effort one way and adding it in another.

At the moment although I have broken the conceptual link between node and host name for the client framework there are still lots of components which are confused by this change. Components have traditionally been able to rely on combining the profile.node and profile.domain resources to form the FQDN. This was probably always on slightly shaky ground but now there can be no guarantee whatsoever of a useful value in the profile.node resource. If a component really cares about the host name (rather than the node name) then it will have to ask the host directly (using hostname or Sys::Hostname from Perl).

Comments are closed.