URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch
This updated patch also sets the date and time strings to the
SOURCE_DATE_EPOCH.
The WHOWHERE string will now be set to simply "openldap" in the case
that a SOURCE_DATE_EPOCH is set.
Tait Communications Ltd hereby place the following modifications to
OpenLDAP Software (and only these modifications) into the public domain.
Hence, these modifications may be freely used and/or redistributed for
any purpose with or without attribution and/or other notice.
Am 2018-10-24 15:57, schrieb Quanah Gibson-Mount:
> --On Wednesday, October 24, 2018 10:21 AM +0000 openldap-its(a)plumbe.de
> wrote:
>
>> Full_Name: Markus Joosten
>> Version: 2.4.44-15.el7
>> OS: CentOS 7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (62.8.242.42)
>>
>>
>> Hello,
>>
>> I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config
>> backend.
>> My main database dc=example,dc=com is replicated using syncrepl,
>> however
>> the retry parameter is completely ignored.
>
> Provide your full configuration minus passwords, as syncrepl is used
> extensively in the test suite and does not exhibit this behavior.
>
> --Quanah
>
I found my error. Turns out I had a runaway double-quote on the type=
parameter like this:
type=refreshAndPersist"
Funny enough, the only message in my log was regarding the missing retry
parameter.
The replication itself was created successfully and was also working as
expected, only the retry parameter was missing.
Regards,
Markus
--On Wednesday, October 24, 2018 10:21 AM +0000 openldap-its(a)plumbe.de
wrote:
> Full_Name: Markus Joosten
> Version: 2.4.44-15.el7
> OS: CentOS 7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (62.8.242.42)
>
>
> Hello,
>
> I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config backend.
> My main database dc=example,dc=com is replicated using syncrepl, however
> the retry parameter is completely ignored.
Provide your full configuration minus passwords, as syncrepl is used
extensively in the test suite and does not exhibit this behavior.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Markus Joosten
Version: 2.4.44-15.el7
OS: CentOS 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (62.8.242.42)
Hello,
I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config backend.
My main database dc=example,dc=com is replicated using syncrepl, however the
retry parameter is completely ignored.
I'm seeing the following log message every time I recreate the replication:
syncrepl rid=001 searchbase="dc=example,dc=com": no retry defined, using
default
Steps to reproduce:
- setup two OpenLDAP servers
- create replication with the retry parameter specified
- retry parameter will be ignored
Regards,
Markus
This is a multi-part message in MIME format.
--------------D22E8F79C8A3AF5F4EEDBDD5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Here's a patch (in git-format-patch format, per the Guidelines for
Contributing) that changes the code comment on mdb_env_set_mapsize to be
consistent with the value of DEFAULT_MAPSIZE.
https://github.com/LMDB/lmdb/compare/mdb.master...mykmelez:default-mapsize.…
(I haven't provided a Notice of Origin nor Rights Statement, as, per the
Guidelines for Contributing, this patch doesn't represent "significant
blocks of new code (10 lines or greater)." It's a one-line change.)
-myk
--------------D22E8F79C8A3AF5F4EEDBDD5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html><head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body
text="#000000" bgcolor="#FFFFFF">
<br>
Here's a patch (in git-format-patch format, per the Guidelines for
Contributing) that changes the code comment on mdb_env_set_mapsize to be
consistent with the value of DEFAULT_MAPSIZE.<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/LMDB/lmdb/compare/mdb.master...mykmelez:default-mapsize.…">https://github.com/LMDB/lmdb/compare/mdb.master...mykmelez:default-mapsize.…</a><br>
<br>
(I haven't provided a Notice of Origin nor Rights Statement, as, per the
Guidelines for Contributing, this patch doesn't represent "significant
blocks of new code (10 lines or greater)." It's a one-line change<font
face="Arial,Verdana,Helvetica">.)<br>
<br>
-myk<br>
<br>
</font>
</body>
</html>
--------------D22E8F79C8A3AF5F4EEDBDD5--
Hello Quanah
Many thanks for your action and answer. In the mean time I noticed that
in this file
ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS
the mirrors are still listed. Could you please update that as well?
Kind regards
Thomas
> Hi Thomas,
>
> --On Thursday, October 11, 2018 12:08 PM +0000 switchmirror(a)switch.ch wrote:
>
>> I already sent twice a message to info(a)openldap.org, but no action or
>> answer received.
>
> The ITS system is the correct spot for this request. ;)
>
>> So I try it on this channel.
>>
>> Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the
>> Download web page:
>> http://www.openldap.org/software/download/
>
> Done.
>
>> BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely
>> disappeared, there is no DNS entry for it anymore.
>
> Thanks, I removed that one as well.
>
> Warm regards,
> Quanah
--
SWITCH
Thomas Lenggenhager, Trust & Identity
Werdstrasse 2, P.O. Box, 8021 Zurich, SWITZERLAND
phone +41 44 268 1505 direct +41 44 268 1541
https://www.switch.ch
--On Friday, February 19, 2016 1:33 AM +0000 quanah(a)zimbra.com wrote:
Played around with this again today, and the issue no longer occurs. It
seems one of the many replication related fixes since I reported this ITS
has solved the problem. Closing the ITS.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Douglas Royds
Version: HEAD
OS: Ubuntu 16.04
URL: ftp://ftp.openldap.org/incoming/douglas-royds-181017.patch
Submission from: (NULL) (202.37.96.2)
To achieve binary-reproducible builds across different build hosts, build paths,
and users, we need to set the WHOWHERE value with something fixed. In this patch
I set it to the SOURCE_DATE_EPOCH if set (see
https://reproducible-builds.org/specs/source-date-epoch/). If you're not trying
to do a reproducible build, it won't be set, so the existing WHOWHERE string
will apply.
Debian have set this string to their own Debian-specific value:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833179
WHOWHERE="$(dpkg-vendor --query vendor) package version
$(dpkg-parsechangelog -SVersion)"
Tait Communications Ltd hereby place the following modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
Hi Thomas,
--On Thursday, October 11, 2018 12:08 PM +0000 switchmirror(a)switch.ch wrote:
> I already sent twice a message to info(a)openldap.org, but no action or
> answer received.
The ITS system is the correct spot for this request. ;)
> So I try it on this channel.
>
> Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the
> Download web page:
> http://www.openldap.org/software/download/
Done.
> BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely
> disappeared, there is no DNS entry for it anymore.
Thanks, I removed that one as well.
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Sunday, October 14, 2018 10:03 PM +0800 =E8=8E=AB=E4=BA=9A=E7=94=B7 =
<nanmor(a)126.com>=20
wrote:
> Run ' ldd /usr/local/openldap.2.4.46/bin/ldapsearch' in Redhat, result:
> linux-vdso.so.1 =3D> (0x00007ffd959d6000)
> libsasl2.so.3 =3D> /lib64/libsasl2.so.3 (0x00007fae80012000)
> libssl.so.10 =3D> /lib64/libssl.so.10 (0x00007fae7fd9f000)
> libcrypto.so.10 =3D> /lib64/libcrypto.so.10
Your Redhat build is linked to the system OpenSSL 1.0.2k release. This=20
clearly won't support TLS 1.3.
lrwxrwxrwx 1 root root 16 Jun 19 14:00 libssl.so.10 -> libssl.so.1.0.2k
Closing this ITS as invalid. I suggest fixing your build process on your=20
RedHat box to link to the correct OpenSSL build. It appears you have the=20
RH openssl development package installed, which is why you're encountering=20
various issues. However, none of this is related to OpenLDAP itself, which =
as I've already noted, behaves correctly when all sides (client & server)=20
are linked to OpenSSL 1.1.1.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>