Project

General

Profile

Actions

Bug #17998

closed

LDAP index inconsistency on update cause error with allowed networks

Added by François ARMAND almost 2 years ago. Updated over 1 year ago.

Status:
Released
Priority:
N/A
Category:
System integration
Target version:
Severity:
User visibility:
Effort required:
Priority:
0

Description

After some Rudder upgrade to 6.1, allowed networks are not available anymore with the following error:

An error occured when trying to get the list of existing allowed networks
Error message was: Error when saving new allowed networks for policy server ${policyServerId.value}

Workaround

You can redo LDAP index (which should have been done during upgrade) on the rudder root server:

$ systemctl stop rudder-slapd
$ su - rudder-slapd -s /bin/sh -c "/opt/rudder/sbin/slapindex" 
$ systemctl start rudder-slapd

Subtasks 2 (0 open2 closed)

Bug #18185: Parent ticket failed to fix the issueReleasedFrançois ARMANDActions
Bug #18186: LDAP index inconsistency on update cause error with allowed networks RejectedActions

Related issues

Related to Rudder - Bug #17967: Missing interpolator in error message for allowed networksReleasedNicolas CHARLESActions
Related to Rudder - Enhancement #18817: Monitor unreference software sizeNewActions
Actions #1

Updated by François ARMAND almost 2 years ago

  • Related to Bug #17967: Missing interpolator in error message for allowed networks added
Actions #2

Updated by François ARMAND almost 2 years ago

  • Description updated (diff)
Actions #3

Updated by François ARMAND almost 2 years ago

  • Description updated (diff)
Actions #4

Updated by Vincent MEMBRÉ almost 2 years ago

  • Target version changed from 6.1.2 to 6.1.3
Actions #5

Updated by François ARMAND almost 2 years ago

  • Target version changed from 6.1.3 to 6.1.4
Actions #6

Updated by Nicolas CHARLES almost 2 years ago

on debian, it happens most probably when during the upgrade, slapd.conf file is replaced by packaging file by user (option -y, or y at all questions)
file is replaced, has the index lines, and so the migration script doesn't see any change

Actions #7

Updated by Nicolas CHARLES almost 2 years ago

we could detect that when update_credentials need to update the credential - in this case we can force the reindex when upgrading to 6.1 from 6.0, but i'm not sure we can detect from which version we upgrade
An idea would be to check the file before upgrade /opt/rudder/etc/openldap/slapd.conf.dpkg-old (on debian) to see if index were there, and if not, reindex (but only if file is not too old)

Also, when credential are changed in update_credentials, we need to restart at least slapd as password used to start it is invalid

Postgresql checks are also invalid:

INFO: Checking PostgreSQL service status............ FAILED

because PGPASSWORD is exported with default password

Actions #8

Updated by Nicolas CHARLES over 1 year ago

we can get last modification date with

stat -c '%Y'  /opt/rudder/etc/openldap/slapd.conf.dpkg-old

and then compare to current time. If < 1 hour, then compare content and reindex if necessary

Actions #9

Updated by Nicolas CHARLES over 1 year ago

  • Status changed from New to In progress
  • Assignee set to Nicolas CHARLES
Actions #10

Updated by Nicolas CHARLES over 1 year ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Nicolas CHARLES to Benoît PECCATTE
  • Pull Request set to https://github.com/Normation/rudder-packages/pull/2361
Actions #11

Updated by Nicolas CHARLES over 1 year ago

  • Status changed from Pending technical review to Pending release
Actions #12

Updated by François ARMAND over 1 year ago

This is still happening on migration from 6.0.8 to 6.1.4 on debian 9

Actions #14

Updated by Vincent MEMBRÉ over 1 year ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 6.1.4 which was released today.

Actions #15

Updated by François ARMAND over 1 year ago

Actions #16

Updated by François ARMAND over 1 year ago

So, the problem in 6.2 seems to be due to changes related to openldap:

- removing indexes on modifyTimestamp helps a lot, on software helps a bit

But even with that, we have a 10x performance lost.
But if we took a web app 6.2 and put it on a 6.1 openldap/vm, it is fast. So something changed with openldap configuration or binaries.

Actions

Also available in: Atom PDF