Project

General

Profile

Actions

Bug #2900

closed

Rudder migration scripts doesn't take into account indexes which could lead to bugs about non-visible groups, directives and rules

Added by Nicolas PERRON over 12 years ago. Updated almost 10 years ago.

Status:
Released
Priority:
1 (highest)
Assignee:
Nicolas PERRON
Category:
Packaging
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

During migration, somes indexes are added int slapd.conf but LDAP are not reindexed. This could lead to bugs about non-visible groups, directives and rules as Rudder make indexes based search.

Actions #1

Updated by Nicolas PERRON over 12 years ago

  • Status changed from New to Discussion
During migration, slapd.conf is not update, then indexes are not changed and this issue should not appear. Nevertheless, there are two exceptions:
  • During a migration from 2.3 to 2.4, schemas and slap.conf are both changed which result in indexes changes without any reindexation.
  • slapd.conf is a configuration file so if with RPM the action is to not update it, with Deb files this is slightly different. The user have the choice to update it or not. If the user update the file, this could lead to the issue described in the ticket.
How could we prevent this situation ?
  • Should we reindex after each update ? (and it could be justifier automatic update of slap.conf indexes)
  • Should we document that any update of the slapd.conf needs a reindexation ?
  • Should we warn at each upgrade process of rudder-inventory-ldap that update slap.conf needs a reindexation ?
Actions #2

Updated by Michael Gliwinski over 12 years ago

Nicolas PERRON wrote:

How could we prevent this situation ?
  • Should we reindex after each update ? (and it could be justifier automatic update of slap.conf indexes)
  • Should we document that any update of the slapd.conf needs a reindexation ?
  • Should we warn at each upgrade process of rudder-inventory-ldap that update slap.conf needs a reindexation ?

IMHO, maybe just document it for now. Switching to the newer cn=config style configuration (instead of slapd.conf) would provide automatic re-indexing (see http://www.openldap.org/doc/admin24/slapdconf2.html) but I'm not sure how much effort it would be to update everything not to rely on slapd.conf.

As you mentioned, slapd.conf is a config file, so there is not guarantee that a user will install it even if you change it in the package, so I'm not sure if re-indexing from e.g. postinst would be effective.

Actions #3

Updated by Jonathan CLARKE over 12 years ago

Michael Gliwinski wrote:

Nicolas PERRON wrote:

How could we prevent this situation ?
  • Should we reindex after each update ? (and it could be justifier automatic update of slap.conf indexes)
  • Should we document that any update of the slapd.conf needs a reindexation ?
  • Should we warn at each upgrade process of rudder-inventory-ldap that update slap.conf needs a reindexation ?

IMHO, maybe just document it for now. Switching to the newer cn=config style configuration (instead of slapd.conf) would provide automatic re-indexing (see http://www.openldap.org/doc/admin24/slapdconf2.html) but I'm not sure how much effort it would be to update everything not to rely on slapd.conf.

That would certainly make it easier, so long as we made the index changes while slapd is *on*line. If *off*line, it doesn't reindex (but you're not supposed to change the cn=config files offline...). However, it's clearly a bit late in the 2.4 release cycle for that kind of change!

As you mentioned, slapd.conf is a config file, so there is not guarantee that a user will install it even if you change it in the package, so I'm not sure if re-indexing from e.g. postinst would be effective.

I think we can detect if the indexes are not the right ones by diffing the output of the following commands:
  • grep ^index /opt/rudder/etc/openldap/slapd.conf | sed 's/\s\+/\t/g' | cut -f2 | sed 's/,/\r\n/g' | sort
  • ls  /var/rudder/ldap/openldap-data/*.bdb | xargs -n 1 -I{} basename {} .bdb | sort | egrep -v '^(dn2id|id2entry)'

If the lists are not the same, then the indexes clearly need updating. This can be put in the postinst, and should solve your problem, but won't cause a reindex to be done on every upgrade.

Actions #4

Updated by Jonathan CLARKE over 12 years ago

  • Status changed from Discussion to Pending technical review
  • % Done changed from 0 to 100

Applied in changeset commit:5ff1a81fa1893709c7fc5d90d494ab3d6629075d.

Actions #5

Updated by Nicolas PERRON over 12 years ago

  • Target version changed from 2.4.0~rc2 to 2.4.0~beta5
Actions #6

Updated by Nicolas PERRON over 12 years ago

It seems good to me.

Actions #7

Updated by Jonathan CLARKE over 12 years ago

  • Status changed from Pending technical review to Released
Actions #8

Updated by Nicolas PERRON almost 12 years ago

  • Project changed from Rudder to 34
  • Category deleted (11)
Actions #9

Updated by Benoît PECCATTE almost 10 years ago

  • Project changed from 34 to Rudder
  • Category set to Packaging
Actions

Also available in: Atom PDF