Rudder

We currently do three things when running an inventory update in Rudder:

• Trigger a fusioninventory-agent run and store the generated inventory XML
• Modify it using the agent to add custom entries
• Send it to the Rudder server

It is a fact that as of now, most of the additions we do using the agent are obsolete, since they are added by FusionInventory itself as part of standard inventory tasks.

We should clean up our custom additions so we may someday be able to eat a vanilla fusioninventory report !

The addition is done in the system technique "techniques/system/inventory/1.0/fusionAgent.st"

The added fields are:

• on android, <OPERATINGSYSTEM> and <ACCESSLOG>. We don't care of that, because Android support must be upgraded in all case. So we should directly patch fusion if still needed in place of adding something fusion is supposed to do (existing tag)
• <VMS><VM></VM></VMS>: not mandatory for Rudder, superseeded by <VIRTUALMACHINES> tag, much more complete and supported since BEFORE Rudder 2.11 / fusionagent 2.3.6 (they are their since at least 2.1.0)
• <USERSLIST><USER></USER></USERLIST>: not mandatory, superseeded by fusion LOCAL_USERS (same as VMS)
• UUID, USER, AGENTSNAME, CFKEY, POLICY_SERVER, HOSTNAME: there are superseeded by the <RUDDER> tag provided in fusion in no more used for real since BEFORE 2.11
• PROCESSORS: it is NO MORE USED since AT LEAST Rudder 2.11
• MACHINEID: It is the same think that in <HARDWARE><UUID>. It used to be buggy with VM, but our is, too, and since 2.11 AT LEAST, if the MACHINEID field does not exists or is empty, we are derivating one from node UUID. So it may lead to some regeneration of machines, but that shouldn't break anything
• SERVER_ROLES: exists only in added tag by CFEngine It was done and in 4.1, it is both under <RUDDER> and at the end in added tags.

So, given all the above, the only actions to do are:

• add SERVER_ROLES to fusioninventory <RUDDER> tag in Rudder 3.1. It is a bug that it wasn't added in that place but in a deprecated one. Add the corresponding parsing in ldap-inventory. On the server, parse that and fall-back with parsing the one outside <RUDDER>
• add support for HARDWARE/UUID, LOCAL_USERS and VIRTUALMACHINES in ldap-inventory with fallback to MACHINEID / USERLIST / VMS in Rudder 3.1

With that, we are able to safely remove ALL added things for nodes up-to-date in 3.1, and as soon as 3.1 - but of course, we won't do it before 4.0.

So, removing addition in 4.0, with the corresponding update in fusion/ldap-inventory in 3.1, covers the cases:

• "last Rudder 3.1 or Rudder 4.0 with nodes in last 3.1, 3.2, or 4.0": as explained, all is good in that case.
• "Rudder 4.0 in other case": as we continue fall-back parsing old place for SERVER_ROLE, LOCAL_USERS and VIRTUALMACHINES, it should just work as before.
• "non last Rudder 3.1 with nodes 4.0": none of the missing tag is mandatory and as soon as the node get its system technique, it will add them (so at worst, first inventory is missing information). We could also keep the old addition only in initial promises for the first time (now that they are merged :)