[Pkg-openldap-devel] Bug#757550: pre-bug discussion: "Backup path (...) unknown (...). Giving up..."

[Ryan Tandy]

Hi,

The issue you are describing is tracked as bug #757550. CCing it now.

https://bugs.debian.org/757550

On Mon, Dec 31, 2018 at 09:34:16PM +0100, pedeb wrote:
>Sorry if this bug is already documented. At least I want to do some
>comments about what I have found.
>
>I'm setting up my first slapd and I'm doing lots of
>
>    dpkg-reconfigure slapd
>
>(would be nice to see idempotent slapd querying style, but you have
>different syntax for different moments; hence, you cannot "modify" if
>the item is not created; buuh)
>
>I see that I'm reaching this error
>
>    Backup path /var/backups/unknown-2.4.44+dfsg-5+deb9u2.ldapdb exists.
>Giving up...
>
>and then database is not being reconfigured !

Correct.

>Very easy to reproduce, change the organization name (myorg) and after
>that you won't see it with:
>
>    root at host:/etc/ldap# grep -ir myorg *
>
>but if you delete the database
>
>    rm -rf /var/backups/unknown-2.4.44+dfsg-5+deb9u2.ldapdb
>
>and `dpkg-reconfigure slapd` again:
>
>    root at host:/etc/ldap# grep -ir myorg *
>    slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcSuffix: dc=myorg
>    slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcRootDN: cn=admin,dc=myorg

Correct.

Other than having to manually delete the previous backup, did it do 
roughly what you would have expected?

>I'm new to debconf stuff so I started looking at it [1]. I appreciate if
>you point me to a reference to understand it better.

For debconf itself, see the debconf-devel(7) man page:

https://manpages.debian.org/stretch/debconf-doc/debconf-devel.7.en.html

>It was a surprise to see the same function (that is related to this
>bug), is in different files (is this in general for all debian
>packages?). I thought that it should be just in one place and source it
>to all this scripts - well, that's probably autogenerated and I would
>like to know what is the official procedure of touching it.

This is a custom thing in the openldap source package. The inclusion is 
done because there isn't a good place to put a library that could be 
sourced; postinst could source things from /usr/share but that doesn't 
work for e.g. config or preinst.

The common part is in slapd.scripts-common:

https://sources.debian.org/src/openldap/2.4.47+dfsg-1/debian/slapd.scripts-common/

and the snippet that includes it into every maintainer script is here:

https://sources.debian.org/src/openldap/2.4.47+dfsg-1/debian/dh_installscripts-common/

That in turn is invoked from debian/rules:

https://sources.debian.org/src/openldap/2.4.47+dfsg-1/debian/rules/#L205

You can find all this by downloading the source package for the version 
you have installed (apt-get source openldap), or clone the git repo 
where the development happens:

https://salsa.debian.org/openldap-team/openldap

>It would be nice to know what is the script executed when I install 
>(apt install slapd) and when I dpkg-reconfigure it (ok, for 
>dpkg-reconfigure it is /var/lib/dpkg/info/slapd.postinst)

The dpkg-reconfigure case is mentioned in debconf-devel(7). The others 
(installation etc) are in Policy:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called
https://www.debian.org/doc/debian-policy/ap-flowcharts.html

>Well, inside that function, receive an argument that if is null then
>"unknown" is set
>
>    # Usage: move_old_database_away <dbdir> [<basedn>]
>    suffix="${2:-unknown}"
>
>trace is:
>
>    compute_backup_path
>    move_old_database_away
>    create_new_configuration
>
>as you see in [1]
>
>is called without a second argument (hence, it is unknown)
>
>    move_old_database_away /var/lib/ldap
>
>if it is not unknown (putting an argument to it), the procedure is still
>failing because the procedure does not able to handle multiple backups
>in case of dealing with the same database (myorg or unknown for example)
>- a workaround is necessary to fix this

That is all correct, and thanks for detailing it.

We could try harder to guess a suffix instead of "unknown", but that 
might still be the best we can do in some cases, f.ex. if /var/lib/ldap 
just contains subdirectories such as dc=example,dc=com and cn=accesslog.

Dealing with multiple backups (reconfiguring the same version multiple 
times, or attempting a failed upgrade starting from the same version) 
still needs to be done, and I haven't settled on a solution for that 
yet, other than it likely involves a timestamp. There is existing code 
for that in compute_backup_path but it isn't used because OLD_VERSION is 
always set.

>Sorry, I feel I'm not reporting this appropiately. But I started looking
>at this without having time and I wanted to share my findings; but I
>know this looks like incomplete thing.

This is fine, thanks for sharing your thoughts! Please CC the bug with 
any further comments or suggestions.

cheers,
Ryan