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@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@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
