Bug #2701
closedAfter a migration from 2.3.8 to 2.4.0~beta3, rudder can't search for itself in Node Management => Search Nodes
Description
After a migration on Debian Squeeze 64 bits, we can't find policy server in the "Search Nodes" section in Node Management.
It could be due to LDAP entries which are not present or not correct (at least 2 modifications to do):- 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
Updated by Nicolas PERRON about 12 years ago
- 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
Updated by Nicolas PERRON about 12 years ago
- 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.
Updated by Jonathan CLARKE about 12 years ago
- 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.
Updated by Nicolas CHARLES about 12 years ago
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
Updated by Jonathan CLARKE about 12 years ago
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.
Updated by Nicolas PERRON about 12 years ago
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.
Updated by Nicolas PERRON about 12 years ago
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
Updated by Nicolas PERRON about 12 years ago
> 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'
Updated by Nicolas PERRON about 12 years ago
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
Updated by Nicolas PERRON about 12 years ago
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
Updated by Nicolas PERRON about 12 years ago
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:- store the variable in a temporary file in /tmp/
- delete the entry in the preinst of rudder-inventory-ldap
- add the new entry and the modifications in rudder-upgrade script
Updated by Nicolas PERRON about 12 years ago
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.
Updated by Nicolas PERRON about 12 years ago
- Status changed from New to Pending technical review
- % Done changed from 0 to 100
All has been made and seems to work since the last commit.
Updated by Jonathan CLARKE almost 12 years ago
- Category set to 11
- Status changed from Pending technical review to Released
Looks good to me.
Updated by Nicolas PERRON over 11 years ago
- Project changed from Rudder to 34
- Category deleted (
11)
Updated by Benoît PECCATTE over 9 years ago
- Project changed from 34 to Rudder
- Category set to Packaging