Rudder

• It seems that a new entry was missing: dn:nodeId=root,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration
• In the dn:ruleId=inventory-all,ou=Rules,ou=Rudder,cn=rudder-configuration, the attribute ruleTarget must be changed from special:all_exceptPolicyServers to special:all
• The entry nodeId=root,ou=Nodes,cn=rudder-configuration must have all attribute removed, except cn, nodeId, description, isSystem, isBroken

I think this is related to the #2699 issue, nodeId=root,ou=Nodes,cn=rudder-configuration is not a new entry but it have too many attributes which result in a fail of rudder-inventory-ldap

• It seems that a new entry was missing: dn:nodeId=root,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration

We have to add a new entry with a script like this:

LDAP_USER=$(grep -E "ldap.authdn=" /opt/rudder/etc/rudder-web.properties |cut -d "=" -f 2-)
LDAP_PASSWORD=$(grep -E "ldap.authpw=" /opt/rudder/etc/rudder-web.properties |cut -d "=" -f 2-)

POLICY_SERVER_HOSTNAME=`/opt/rudder/bin/ldapsearch -H ldap://localhost -x -w secret -D "cn=manager,cn=rudder-configuration" -b nodeId=root,ou=Nodes,cn=rudder-configuration -LLL "(nodeHostname=*)" |\
grep "nodeHostname" |\
cut -d ':' -f2 | cut -d' ' -f2`

/opt/rudder/bin/ldapadd -x -D ${LDAP_USER} -w ${LDAP_PASSWORD} -H ldap://localhost << EOF
dn: nodeId=root,ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration
objectClass: top
objectClass: node
objectClass: unixNode
objectClass: linuxNode
nodeId: root
osKernelVersion: 1.0-dummy-version
osName: Linux
osVersion: Linux
localAccountName: root
cn: root
localAdministratorAccountName: root
nodeHostname: ${POLICY_SERVER_HOSTNAME}
PolicyServerId: root
inventoryDate: 19700101000000+0200
receiveDate: 19700101000000+0200
ipHostNumber: 127.0.0.1
agentName: Community
publicKey: Currently not used
EOF

The problem with this is that the schema doesn't allow us to add this entry.

• In the dn:ruleId=inventory-all,ou=Rules,ou=Rudder,cn=rudder-configuration, the attribute ruleTarget must be changed from special:all_exceptPolicyServers to special:all

Easy, a simple ldapmodify with this:

dn: ruleId=inventory-all,ou=Rules,ou=Rudder,cn=rudder-configuration
changetype: modify
replace: ruleTarget
ruleTarget: special:all

• The entry nodeId=root,ou=Nodes,cn=rudder-configuration must have all attribute removed, except cn, nodeId, description, isSystem, isBroken

Here, a ldapmodify too with this:

dn: nodeId=root,ou=Nodes,cn=rudder-configuration
changetype: modify
delete: nodeHostname
delete: publicKey
delete: ipHostNumber
delete: agentName
delete: inventoryDate
delete: localAdministratorAccountName
delete: policyServerId

But be aware that for adding the first entry we have to check nodeHostname from this one.

I'm unsure about the logic behind these changes, but some comments anyway:

• The node hostname is actually the root server hostname. This is more easily obtained with the command "hostname --fqdn"
• Why do you say the schema won't allow adding some entries? If this is the case then either your entry or the schema is broken.

Jonathan CLARKE wrote:

I'm unsure about the logic behind these changes, but some comments anyway:

• The node hostname is actually the root server hostname. This is more easily obtained with the command "hostname --fqdn"
• Why do you say the schema won't allow adding some entries? If this is the case then either your entry or the schema is broken.

Caution, the hostname is the one that the user select during the init script, that the nodes should use to connect to it. It may be something else (like an IP address if the DNS config is not valid)
This value should be retrieved from the value of the attribute nodeHostname from the nodeId=root,ou=Nodes,cn=rudder-configuration before the migration script

Nicolas CHARLES wrote:

Jonathan CLARKE wrote:

I'm unsure about the logic behind these changes, but some comments anyway:

• The node hostname is actually the root server hostname. This is more easily obtained with the command "hostname --fqdn"
• Why do you say the schema won't allow adding some entries? If this is the case then either your entry or the schema is broken.

Caution, the hostname is the one that the user select during the init script, that the nodes should use to connect to it. It may be something else (like an IP address if the DNS config is not valid)
This value should be retrieved from the value of the attribute nodeHostname from the nodeId=root,ou=Nodes,cn=rudder-configuration before the migration script

OK, that's good to know. Agreed.

Jonathan CLARKE wrote:

I'm unsure about the logic behind these changes, but some comments anyway:

• The node hostname is actually the root server hostname. This is more easily obtained with the command "hostname --fqdn"
• Why do you say the schema won't allow adding some entries? If this is the case then either your entry or the schema is broken.

I was considering that these changes wasn't intended so that the schema will not allow these changes.
For adding the new entry, i've got this message:

adding new entry "nodeId=root,ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" 
ldap_add: Undefined attribute type (17)
    additional info: receiveDate: attribute type undefined

But it was because of 'nodeHostname: ${POLICY_SERVER_HOSTNAME}' which wasn't interpreted.

Nicolas PERRON wrote:

Jonathan CLARKE wrote:

I'm unsure about the logic behind these changes, but some comments anyway:

• The node hostname is actually the root server hostname. This is more easily obtained with the command "hostname --fqdn"
• Why do you say the schema won't allow adding some entries? If this is the case then either your entry or the schema is broken.

I was considering that these changes wasn't intended so that the schema will not allow these changes.
For adding the new entry, i've got this message:
[...]

But it was because of 'nodeHostname: ${POLICY_SERVER_HOSTNAME}' which wasn't interpreted.

The error message indicates that it's about a missing attribute in the schema: receiveDate

I've added it in /opt/rudder/etc/openldap/schema/inventory.schema , restarted sladp and retry. A new error message is displayed:

adding new entry "nodeId=root,ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" 
ldap_add: Object class violation (65)
    additional info: attribute 'receiveDate' not allowed

> But it was because of 'nodeHostname: ${POLICY_SERVER_HOSTNAME}' which wasn't interpreted.

I was complety wrong, the variable ${POLICY_SERVER_HOSTNAME} has been interpreted.
Adding receiveDate like on the commit 3175a9258ce2e31cf0c5a885916a62b99b9c562b suffice to be able to add the new entry:

--- /opt/rudder/etc/openldap/schema/inventory.schema.old        2012-07-26 04:34:00.000000000 -0400
+++ /opt/rudder/etc/openldap/schema/inventory.schema    2012-07-26 04:37:19.000000000 -0400
@@ -288,6 +288,13 @@
   ORDERING generalizedTimeOrderingMatch )

 attributetype ( InventoryAttributes:300.12
+  NAME 'receiveDate'
+  DESC 'Last time an inventory was received for that element'
+  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+  EQUALITY generalizedTimeMatch
+  ORDERING generalizedTimeOrderingMatch )
+
+attributetype ( InventoryAttributes:300.13
   NAME 'agentName'
   DESC 'List of name of the agent (Nova, Community, ...)'
   EQUALITY caseIgnoreMatch
@@ -665,7 +672,7 @@
   DESC 'A container for servers, ie a physical machine or a virtual machine'
   SUP device
   MUST ( machineId )
-  MAY ( cn $ description $ motherBoardUuid $ confirmed $ inventoryDate ) )
+  MAY ( cn $ description $ motherBoardUuid $ confirmed $ inventoryDate $ receiveDate ) )

 objectclass ( InventoryObjectClasses:2
   NAME 'physicalMachine'
@@ -797,7 +804,7 @@
         software $  localAccountName $ osServicePack $
         nodePolicies $ ram $ swap $ confirmed $
         inventoryDate $ ipHostNumber $ osFullName $
-        osArchitectureType $ lastLoggedUser $ lastLoggedUserTime ) )
+        osArchitectureType $ lastLoggedUser $ lastLoggedUserTime $ receiveDate ) )

 objectclass ( InventoryObjectClasses:15
   NAME 'windowsNode'

The name of attributes and entries have changed between 2.3 and 2.4, so the right instruction to modify the others entries are:

• In the dn:ruleId=inventory-all,ou=Rules,ou=Rudder,cn=rudder-configuration, the attribute ruleTarget must be changed from special:all_exceptPolicyServers to special:all

/opt/rudder/bin/ldapmodify -x -D ${LDAP_USER} -w ${LDAP_PASSWORD} -H ldap://localhost << EOF
dn: configurationRuleId=inventory-all,ou=Configuration Rules,ou=Rudder,cn=rudder-configuration
changetype: modify
replace: configurationRuleTarget
configurationRuleTarget: special:all
EOF

• The entry nodeId=root,ou=Nodes,cn=rudder-configuration must have all attribute removed, except cn, nodeId, description, isSystem, isBroken

For this one, a new problem appears. Like the first one, the new schema will not permit the attributes I have to delete but the old one doesn't permit to delete them.

A solution could be to delete the entry, modify the schema and only then, add the entry with the good attributes

Nicolas PERRON wrote:

The name of attributes and entries have changed between 2.3 and 2.4, so the right instruction to modify the others entries are:

• In the dn:ruleId=inventory-all,ou=Rules,ou=Rudder,cn=rudder-configuration, the attribute ruleTarget must be changed from special:all_exceptPolicyServers to special:all

[...]

• The entry nodeId=root,ou=Nodes,cn=rudder-configuration must have all attribute removed, except cn, nodeId, description, isSystem, isBroken

For this one, a new problem appears. Like the first one, the new schema will not permit the attributes I have to delete but the old one doesn't permit to delete them.

A solution could be to delete the entry, modify the schema and only then, add the entry with the good attributes

• First step, delete this entry
  

  /opt/rudder/bin/ldapdelete -x -D ${LDAP_USER} -w ${LDAP_PASSWORD} -H ldap://localhost "nodeId=root,ou=Nodes,cn=rudder-configuration" 
  

• Second step, make the upgrade

• Third step, add a new nodeId=root,ou=Nodes,cn=rudder-configuration entry:

/opt/rudder/bin/ldapadd -x -D ${LDAP_USER} -w ${LDAP_PASSWORD} -H ldap://localhost << EOF
dn: nodeId=root,ou=Nodes,cn=rudder-configuration
objectClass: rudderPolicyServer
objectClass: rudderNode
objectClass: top
cn: root
isBroken: FALSE
isSystem: TRUE
nodeId: root
description: the policy server
EOF

The deletion must be done before migration of LDAP and the new entry must include variable based on an attribute of the deleted entry.

A solution could be to:

1. store the variable in a temporary file in /tmp/
2. delete the entry in the preinst of rudder-inventory-ldap
3. add the new entry and the modifications in rudder-upgrade script

We have decided to use a migration script like with the change of the name of all LDAP entries and attributes which was named "policy instance", "configuration rules", etc...

The problem here was that Rudder have two declarations of nodes in the LDAP:

• Simple node's information for Rudder ou=Nodes,cn=rudder-configuration
• Detailed accepted node's information for the inventories ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration

On the branch 2.3, the root server doesn't have any inventory and can't be considered as an accepted node. Then, a choice has been made to give some details (eight attributes: nodeHostname, publicKey, ipHostNumber, agentName, inventoryDate, localAdministratorAccountName, policyServerId) on the root server entry of ou=Nodes,cn=rudder-configuration as it can't exist on ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration to compensate the fact that root server can't have an inventory.

On the branch 2.4, the root server can send inventories and is considered as an accepted node then what have be described above had to be changed in order to be more consistent. All of the extra details on ou=Nodes,cn=rudder-configuration for the root server has been migrated to the detailed node in ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration and the schema has been modified in order to make sure that entries in ou=Nodes,cn=rudder-configuration have only a few informations.

During the transition from 2.3 to 2.4, the informations of the entry of the root server in ou=Nodes,cn=rudder-configuration aren't compatible with the schema on 2.4 then the eight extra informations have to be moved to the root server entry in ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration.

For theses actions we have chosen to use a migration script from rudder-inventory-ldap package which will do the job with slapd down and before Rudder needs to use openLDAP. The action is simple:

• A backup of the openLDAP base is made
• From the backup, the entry nodeId=root,ou=Nodes,cn=rudder-configuration is parsed and rewritten
• If an extra information is detected, the information is stored and not rewritten
• From the backup, the entry nodeId=root,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration is parsed and rewritten with the stored informations above.
• The modified backup is reinserted in the openLDAP base.