Bug#812515: slapd: upgrading slapd with several databases

2016-01-24 Thread Samuel Thibault
Package: slapd
Version: 2.4.31-2+deb7u1
Severity: serious
Justification: database upgrade failed

Hello,

I at last upgraded our old ldap server to wheezy (yes, that's already
old, but the kind of upgrade issues we are having as described here
doesn't motivate to do it), and it went wrong:

  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.23-7.3+deb6u2... done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.4.23-7.3+deb6u2: 
  - directory dc=aquilenet,dc=fr... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
56a4e83c olcDbDirectory: value #0: invalid path: No such file or directory
56a4e83c config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
slapadd: bad configuration directory!

What is notable with our ldap database is that it has one domain
(dc=aquilenet,dc=fr, in {1}hdb) in /var/lib/ldap:

olcDbDirectory: /var/lib/ldap

, and another domain (dc=girondix,dc=net, in {2}hdb) in
/var/lib/ldap/NET:

olcDbDirectory: /var/lib/ldap/NET

Since the upgrade scripts move the content of /var/lib/ldap out, loading
the second database fails since /var/lib/ldap/NET doesn't exist.

The crude way we have fixed it is to add, in load_databases, just after
checking that $dbdir is empty, an mkdir /var/lib/ldap/NET, so that the
load succeeds, I then get:

  BBacking up /etc/ldap/slapd.d in /var/backups/slapd-2.4.23-7.3+deb6u2... done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.4.23-7.3+deb6u2: 
target is /var/lib/ldap
  - directory dc=aquilenet,dc=fr... done.
  - chowning database directory (openldap:openldap)... done
target is /var/lib/ldap/NET
  - directory dc=girondix,dc=net... done.
  - chowning database directory (openldap:openldap)... done

I guess a proper way to do it would be to just create all olcDbDirectory
directories recorded in the database configuration.

Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'oldoldstable'), 
(500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
 FYLG> Tiens, vlĂ  une URL qui va bien :
 FYLG> ftp://127.0.0.1/WaReZ/NiouZeS/WinDoZe/NeWSMoNGeR/SuPeR
 c'est gentil sauf que l'adresse ne fonctionne pas sa me fais une erreur
 -+- Furtif in Guide du Neuneu Usenet :  -+-



Bug#812515: slapd: upgrading slapd with several databases

2016-01-24 Thread Ryan Tandy

Control: fixed -1 2.4.40-1

On Sun, Jan 24, 2016 at 04:24:20PM +0100, Samuel Thibault wrote:

What is notable with our ldap database is that it has one domain
(dc=aquilenet,dc=fr, in {1}hdb) in /var/lib/ldap:

olcDbDirectory: /var/lib/ldap

, and another domain (dc=girondix,dc=net, in {2}hdb) in
/var/lib/ldap/NET:

olcDbDirectory: /var/lib/ldap/NET


This sounds exactly like LP: #1003854, which has been fixed in jessie:

https://bugs.launchpad.net/bugs/1003854

I'm not sure about fixing this in wheezy. At this point in its life I'm 
quite reluctant to do anything that might risk introducing a regression. 
But if people are still upgrading from squeeze, then others will 
probably still run into bugs like this one...




Processed: Re: Bug#812515: slapd: upgrading slapd with several databases

2016-01-24 Thread Debian Bug Tracking System
Processing control commands:

> fixed -1 2.4.40-1
Bug #812515 [slapd] slapd: upgrading slapd with several databases
Marked as fixed in versions openldap/2.4.40-1.

-- 
812515: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812515
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems