Project

General

Profile

Actions

Bug #10505

closed

During a migration from 4.0 to 4.1, ldap base was emptied

Added by François ARMAND about 7 years ago. Updated about 7 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
System integration
Target version:
Severity:
Critical - prevents main use of Rudder | no workaround | data loss | security
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Priority:
60
Name check:
Fix check:
Regression:

Description

I'm not exactly sure about what happened, I don't see error in the process, but after the upgrade, the LDAP base is completely empty (not even root object).

The first symptom was that there was no CSS/JS at all, which is strange and reminds #10430.
The webapp logs are full of LDAP errors:

[2017-03-24 14:51:26] ERROR com.normation.rudder.repository.ldap.LDAPGitRevisionProvider - The root entry of the user template library was not found, the current revision won't be persisted
[2017-03-24 14:51:28] ERROR com.normation.ldap.sdk.ROPooledSimpleAuthConnectionProvider - Can't execute LDAP request
com.unboundid.ldap.sdk.LDAPSearchException: no such object
>-at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3650)
...
[2017-03-24 14:51:28] ERROR com.normation.ldap.sdk.ROPooledSimpleAuthConnectionProvider - Can't execute LDAP request
com.unboundid.ldap.sdk.LDAPSearchException: no such object
>-at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3650)

An ldapsearch returned excatly nothing:

root@server:/var/rudder/ldap/backup# ldapsearch -v -h localhost -p 389  -x -D "cn=Manager,cn=rudder-configuration" -w b385ddd5a0b4 -b "cn=rudder-configuration" -s sub "1.1" 

ldap_initialize( ldap://localhost:389 )
filter: (objectclass=*)
requesting: 1.1
# extended LDIF
#
# LDAPv3
# base <cn=rudder-configuration> with scope subtree
# filter: (objectclass=*)
# requesting: 1.1
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

So, this was easely solved by restauring the pre-migration backup, but it is not quite satisfying:

$ service rudder-slapd stop
$ cd /var/rudder/ldap/backup
$ gunzip openldap-data-pre-upgrade-20170324143846.ldif.gz
$ /opt/rudder/sbin/slapadd -l openldap-data-pre-upgrade-20170324143846.ldif
$ /etc/init.d/rudder-slapd start
$ service rudder-jetty restart

Related issues 2 (0 open2 closed)

Related to Rudder - Bug #10430: Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server)RejectedActions
Is duplicate of Rudder - Bug #10517: slapd migration for 4.1 is not done on Ubuntu 16.04ReleasedBenoît PECCATTEActions
Actions #1

Updated by François ARMAND about 7 years ago

  • Subject changed from During a migration from 4.0 to 4.1, ldap base was empty to During a migration from 4.0 to 4.1, ldap base was emptied
Actions #2

Updated by François ARMAND about 7 years ago

  • Related to Bug #10430: Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server) added
Actions #3

Updated by François ARMAND about 7 years ago

  • Severity set to Critical - prevents main use of Rudder | no workaround | data loss | security
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings
Actions #4

Updated by François ARMAND about 7 years ago

I can trigger it if during a migration, I'm replying "Y" to the conf file update of slapd:

Configuration file '/opt/rudder/etc/openldap/slapd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** slapd.conf (Y/I/N/O/D/Z) [default=N] ?

But I wasn't able to reproduce it in the normal, documented update process.

Actions #5

Updated by François ARMAND about 7 years ago

The reason is that if we choose to get the new config file version, not database migration is triggered, and Ragnarök ensues.

Actions #6

Updated by François ARMAND about 7 years ago

  • Related to Bug #10517: slapd migration for 4.1 is not done on Ubuntu 16.04 added
Actions #7

Updated by Benoît PECCATTE about 7 years ago

  • Priority set to 2
Actions #8

Updated by Benoît PECCATTE about 7 years ago

  • Priority changed from 2 to 1
Actions #9

Updated by Benoît PECCATTE about 7 years ago

  • Priority changed from 1 to 0
Actions #10

Updated by Benoît PECCATTE about 7 years ago

  • Priority changed from 0 to 50
Actions #11

Updated by Benoît PECCATTE about 7 years ago

  • Priority changed from 50 to 100
Actions #12

Updated by Benoît PECCATTE about 7 years ago

  • Priority changed from 100 to 60
Actions #13

Updated by François ARMAND about 7 years ago

  • Status changed from New to Rejected

Since #10517, the migration is done EVEN if the user didn't read the document and answered [Y] to use the new slapd.conf config file. So now, the only problem remaining when you don't follow the document is that the password won't be correct until next agent run.

So I'm closing that ticket, and I'm marking it a duplicate of #10517 (the cause was the same).

Actions #14

Updated by François ARMAND about 7 years ago

  • Related to deleted (Bug #10517: slapd migration for 4.1 is not done on Ubuntu 16.04)
Actions #15

Updated by François ARMAND about 7 years ago

  • Is duplicate of Bug #10517: slapd migration for 4.1 is not done on Ubuntu 16.04 added
Actions

Also available in: Atom PDF