Bug #2609
closed
After an upgrade from 2.4.0~alpha7 to a nightly build, LDAP connections could not be established
Description
After restarted all services link by Rudder, this error is displayed on the WebUI:
Failure(Deployment error for process '233' at 2012/06/27 17:41:21,Empty,Full(Failure(Cannot build Rule vals,Empty,Full(Failure(Could not find configuration vals,Empty,Full(Failure(Can't get a new LDAP connection,Full(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server localhost:389: java.io.IOException: An error occurred while attempting to establish a connection to server localhost:389: java.net.ConnectException: Connection refused')),Empty)))))))
Into the log, it doesn't seem to be any error about LDAP:
18:14:10.080 [pool-3-thread-4] ERROR com.normation.rudder.batch.CheckTechniqueLibrary$LAUpdateTechLibManager - Ignoring start update dynamic group request because one other update still processing
18:14:10.086 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276736] Start search for { returnType:'node' with 'And' criteria [node.OS eq Linux] }
18:14:10.086 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276736] |- LDAPObjectType(ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration,One,(objectClass=linuxNode),DNJoin,Set())
18:14:10.091 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276736] `-> 10 results
18:14:10.138 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276737] Start search for { returnType:'node' with 'And' criteria [node.OS eq Linux ; node.osName eq Centos ; node.osVersion lt 7] }
18:14:10.138 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276737] |- LDAPObjectType(ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration,One,(&(objectClass=linuxNode)(&(objectClass=node)(osName=Centos))(&(osVersion=*)(!(osVersion>=7)))),DNJoin,Set())
18:14:10.140 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276737] `-> 3 results
18:14:10.161 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276738] Start search for { returnType:'node' with 'Or' criteria [node.osVersion eq 6.2 ; node.osVersion eq 11 ; node.osVersion eq 6.0.4] }
18:14:10.161 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276738] |- LDAPObjectType(ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration,One,(|(osVersion=6.2)(osVersion=11)(osVersion=6.0.4)),DNJoin,Set())
18:14:10.163 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276738] `-> 3 results
18:14:10.177 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276739] Start search for { returnType:'node' with 'And' criteria [node.osName eq Ubuntu] }
18:14:10.178 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276739] |- LDAPObjectType(ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration,One,(&(objectClass=node)(osName=Ubuntu)),DNJoin,Set())
18:14:10.179 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276739] `-> 2 results
18:14:10.190 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276740] Start search for { returnType:'node' with 'And' criteria [node.osName eq Suse ; node.OS eq Linux ; node.nodeHostname regex frcdg[0-9]+.*] }
18:14:10.191 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276740] |- LDAPObjectType(ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration,One,(&(&(objectClass=node)(osName=Suse))(objectClass=linuxNode)(objectClass=*)),DNJoin,Set())
18:14:10.192 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276740] `-> 0 results
18:14:10.200 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276741] Start search for { returnType:'node' with 'And' criteria [node.osName eq Debian ; node.ram gteq 200 MB] }
18:14:10.200 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276741] |- LDAPObjectType(ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration,One,(&(&(objectClass=node)(osName=Debian))(ram>=209715200)),DNJoin,Set())
18:14:10.202 [pool-3-thread-3] DEBUG com.normation.rudder.services.queries.InternalLDAPQueryProcessor - [196268276741] `-> 1 results
18:14:10.210 [pool-3-thread-2] DEBUG com.normation.rudder.batch.UpdateDynamicGroups$LAUpdateDyngroupManager - Dynamic group update started at 2012/06/27 18:14:10, ended at 2012/06/27 18:14:10
Updated by Nicolas PERRON over 12 years ago
- Subject changed from After an upgrade from 2.4.0~alpha7 to a nightly build, LDAP connections could ne be established to After an upgrade from 2.4.0~alpha7 to a nightly build, LDAP connections could not be established
Updated by Nicolas PERRON over 12 years ago
I can't understand. This bug is not reproducible.
It suppose we can reject it.
Updated by François ARMAND over 12 years ago
- Status changed from New to Discussion
- Priority changed from 1 (highest) to 4
The given error is quite clear: the server wasn't available when the action was performed.
By luke, the LDAP connection is based on a connection pool able to invalidate lost connection, retry latter to see if the LDAP directory is up, etc. So it may just what happen: the LDAP server was unavailable for a short period of time during which the deployment action was attempted, and then come back on-line, and so next connection were successful.
I don't think it can be qualified as a bug, safe for the wrong looking of the error message (how does that appears exactly ?)
At least, priority is not 1.
Updated by Nicolas PERRON over 12 years ago
François ARMAND wrote:
The given error is quite clear: the server wasn't available when the action was performed.
By luke, the LDAP connection is based on a connection pool able to invalidate lost connection, retry latter to see if the LDAP directory is up, etc. So it may just what happen: the LDAP server was unavailable for a short period of time during which the deployment action was attempted, and then come back on-line, and so next connection were successful.
I don't think it can be qualified as a bug, safe for the wrong looking of the error message (how does that appears exactly ?)
I 've made an upgrade, let the server restart and be up and after logging into the WebUI an error occurred at the top right corner of the page like when promises can't be generated. The pop up displayed the error I've write on.
At least, priority is not 1.
I suppose so.
Updated by Nicolas PERRON over 12 years ago
- Target version changed from 2.4.0~beta2 to 2.4.0~beta3
2.4.0~beta2 has been released. This ticket must be moved to 2.4.0~beta3.
Updated by Jonathan CLARKE over 12 years ago
- Status changed from Discussion to Rejected
Rejecting this bug as we've tested several upgrades that worked fine, and this is not reproducible.