[Pkg-openldap-devel] OpenLDAP 2.4.7
Quanah Gibson-Mount
quanah at zimbra.com
Mon Dec 17 21:34:16 UTC 2007
--On December 16, 2007 12:37:07 PM -0800 Russ Allbery <rra at debian.org>
wrote:
>> ... and then I went and made the change to build-depend on libgnutls-dev
>> instead of libssl-dev which I'd forgotten to do before, and now the
>> package FTBFS. :) Looks like this is related to having support for
>> lanman password hashes enabled; I would recommend simply disabling
>> these, since these are a horribly weak, pre-NT encryption (not NT and
>> above, as the bug submitter claimed when requesting this feature be
>> enabled).
>
> That sounds reasonable to me. I doubt anyone was particularly excited
> about porting that code to GnuTLS. Although we should probably also
> report that as an upstream bug too, just in case anyone has a free moment
> to care.
Out of curiousity, upstream with who? I got lost here. :P
>>> We're using delta-syncrepl with something very close to the current
>>> Debian packages without any trouble, so I don't think you'll need any
>>> other packaging.
>
>> So you don't think there's a need to detect when users have slurpd
>> enabled, and provide some warning that it will cease to be available on
>> upgrade and require manual adjustments? Debconf error template,
>> NEWS.Debian or something?
>
> Oh, I see what you're saying now.
>
> Yes, I definitely think that a NEWS.Debian entry would be in order.
> Beyond that, hm, if we can detect that people are using slurpd, we should
> probably try to issue an error via debconf. Quanah, could you comment
> here on how to detect this and what the reasonable upgrade path would be?
Well, there are a couple of issues here. One is that slurpd was global,
where as syncrepl is per database. Since there can be multiple databases
in a slapd.conf file, one has no idea really how to convert such a scenario
to use syncrepl. The other is that syncrepl is pull driven rather than
push driven. I.e., in the past, slurpd would just write to the slave
using some set of credentials. There's no guarantee that that same set of
credentials supplied in reverse would work (i.e., have the read permissions
necessary on the master). So I think the only real way to handle this is
to force users to manual upgrade their slapd.conf if they used slurpd.
--Quanah
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
More information about the Pkg-openldap-devel
mailing list