syncrepl not working: "no serverID / URL match found"
by Daniel Spannbauer
Hello,
at the moment we have an server running openSuSE 11.4 (lets call in
server2), running openldap 2.4.23.
Configured is a replication to/from out mainoffice (running openldap
2.4.17, server1).
Replication works fine.
I wan't to replace server2 with a newer one, running openldap 2.4.33 atm.
----------------------------------------------
Configuration for replication on server2:
moduleload syncprov.la
serverID 1 "ldap://server1.mainoffice.xxx.de"
serverID 2 "ldap://server2.branch.xxx.de"
overlay syncprov
syncrepl rid=001
provider=ldap://server1.mainoffice.xxx.de:389
binddn="cn=Administrator,dc=xxx,dc=de"
bindmethod=simple
credentials=somepassowrd
searchbase=" dc=marco,dc=de"
type=refreshAndPersist
interval=00:00:00:10
retry="5 5 300 +"
timeout=1
mirrormode TRUE
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
syncprov-checkpoint 1000 60
----------------------------------------------
This config works fine with the "old" 2.4.23, but on 2.4.33 I get the
following error when I start it on the commandline with
/usr/lib/openldap/slapd -h ldap:/// -f /etc/openldap/slapd.conf -u
ldap -g ldap -o slp=off -d 1
57ff35cc read_config: no serverID / URL match found. Check slapd -h
arguments.
Any hints about this?
regards
Daniel
--
Daniel Spannbauer Systemadministration
marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11
Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220
http://www.marco.de/ Email ds(a)marco.de
Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München
6 years, 5 months
Re: syncrepl not working: "no serverID / URL match found"
by Quanah Gibson-Mount
--On Thursday, October 13, 2016 10:22 AM +0200 Daniel Spannbauer
<ds(a)marco.de> wrote:
> serverID 1 "ldap://server1.mainoffice.xxx.de"
> serverID 2 "ldap://server2.branch.xxx.de"
> This config works fine with the "old" 2.4.23, but on 2.4.33 I get the
> following error when I start it on the commandline with
> /usr/lib/openldap/slapd -h ldap:/// -f /etc/openldap/slapd.conf -u
> ldap -g ldap -o slp=off -d 1
>
> 57ff35cc read_config: no serverID / URL match found. Check slapd -h
> arguments.
Hi Daniel,
As the error message notes, there is no match between what you are passing
to -h when slapd starts (ldap:///) and a URI in your serverID config
(ldap://server1... ldap://server2...).
Adjust your -h option to slapd so that it can be matched against a server
ID.
Hope that helps!
--Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 5 months
Re: LMDB: Ignore SIGPIPE in mdb_env_copythr
by Howard Chu
Lorenz Bauer wrote:
> Hello Hallvard, List,
>
> I'd like to propose explicitly ignoring SIGPIPE in the copy thread via
> pthread_sigmask, and returning EPIPE to the caller instead.
Feel free to submit a patch to the ITS, according to
http://www.openldap.org/devel/contributing.html
Since it seems this is a pretty small change, I suggest your IPR notice should
place your changes into the public domain.
>
> This is a change that makes little sense in the C world, since the
> caller can simply adjust the sigmask before calling the function
> (which is indeed what the utilities do). However, this amount of
> control is not always given, e.g. when using LMDB from Go (which is
> what I am doing).
>
> Due to the way the Go runtime works, using mdb_env_copyfd2 with
> CP_COMPACT on a pipe or a network connection will abort the whole
> process with SIGPIPE if the reading end of the fd is closed
> prematurely. The details why this happens are in [1]. Go has some
> additional trickery when dealing with stdin and stdout, so ignoring
> SIGPIPE for the whole process is undesirable (details in [2]).
>
> I understand that you might be reluctant to change the behaviour due
> to the constraints of a different runtime. However, I think that even
> in the C world it is surprising that calling a library function can
> abort your process.
>
> What are your thoughts regarding this? I think the code changes would
> be small, and the API would not change for consumers of the library.
>
> 1: https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG
> 2: https://golang.org/pkg/os/signal/#hdr-SIGPIPE
>
> Best,
> Lorenz
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 5 months
group membership search performance
by Rébeli-Szabó Tamás
Hi,
we are on OpenLDAP 2.4.41 + MDB, Oracle Linux 6 (2.6 x86_64).
In our DIT we have around 300 groups, with tens of thousands of members
in each group. When we want to know which groups a certain user belongs
to, it takes OpenLDAP several seconds to perform such a search.
Here is a log excerpt showing that it took 6 seconds for the server to
answer:
Oct 10 15:39:38 ldap-srv1 slapd[14776]: conn=1062 op=1 SRCH
base="ou=groups,dc=tt,dc=hu" scope=1 deref=0
filter="(&(uniqueMember=uid=o10011,ou=users,dc=tt,dc=hu)(objectClass=groupOfUniqueNames))"
Oct 10 15:39:44 ldap-srv1 slapd[14776]: conn=1062 op=1 SEARCH RESULT
tag=101 err=0 nentries=127 text=
We have eq indices on objectClass and uniqueMember, and the latter is
also listed after sortvals.
The machine running OpenLDAP has 2 virtual cores of Intel Xeon E5 2637
v2 (3.5GHz). During such searches, one of the CPU cores is almost fully
loaded, but the system is not overloaded (the average load is around
0.8). Our whole dataset is under 1 GB, and there are several gigabytes
of free RAM with no swapping.
Our expectation would be for OpenLDAP to give an answer to a group
membership question under 1 second. Is that a realistic expectation, and
if so, how should we tune OpenLDAP or what do you suggest we change?
Version 2.4.41 is more than a year old, so the question is if there is
any significant performance enhancement (an order of magnitude) possible
with this setup described above, or that's about all we can get from
OpenLDAP+MDB (or perhaps any in-memory LDAP)?
Regards,
tamas
6 years, 5 months
Returned mail: Data format error
by dieter＠dkluenter.de
Dear user openldap-technical(a)openldap.org,
Your account has been used to send a huge amount of junk e-mail during this week.
Obviously, your computer was compromised and now runs a hidden proxy server.
Please follow instructions in order to keep your computer safe.
Virtually yours,
openldap.org user support team.
6 years, 5 months
Paged Result support in proxy cache
by laurent2.perrin＠orange.com
Hello,
I have configured a proxy LDAP with cache but when I try to do request with paged results, I can see this error message in logs:
Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1 SRCH base="dc=***,dc=***,dc=****,dc=**" scope=2 deref=0 filter="(&(memberOf=cn=gg-oab-pa-openstack,ou=profils applicatifs,ou=groupes de securite \28gg\29,ou=***,dc=***,dc=***,dc=***,dc=***)(objectClass=person)(?SAMACCOUNTNAME=*))"
Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1 SRCH attr=samaccountname userPassword userAccountControl mail description
Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1: critical pagedResults control disabled with proxy cache.
Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1: critical control "1.2.840.113556.1.4.1339" not supported.
Oct 7 14:07:55 ldap-cache slapd[18615]: send_ldap_result: conn=1017 op=1 p=3
Oct 7 14:07:55 ldap-cache slapd[18615]: send_ldap_result: err=12 matched="" text=""
Oct 7 14:07:55 ldap-cache slapd[18615]: send_ldap_response: msgid=2 tag=101 err=12
Oct 7 14:07:55 ldap-cache slapd[18615]: conn=1017 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=
When the cache is not configured, all requests are OK and return results
Here is the configuration used:
dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: ldap
olcSuffix: dc=ad-***,dc=***,dc=***,dc=**
olcRootDN: cn=compte_service,OU=***,dc=***,dc=***,dc=***,dc=***
olcRootPW: password
olcDbURI: "ldap://ad.local"
olcDbChaseReferrals: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbACLBind: bindmethod=simple binddn="cn= ***,OU=***,dc=***,dc=*,dc=***,dc=***" credentials="password"
olcLimits: * size.prtotal=unlimited size.pr=1000 size.hard=5000
dn: olcOverlay=pcache,olcDatabase={2}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcPcacheConfig
olcOverlay: pcache
olcPcache: hdb 100000 1 1000 100
olcPcacheAttrset: 0 *
olcPcacheTemplate: "(sn=)" 0 3600 0 0 0
olcPcacheTemplate: "(memberof=)" 0 3600
dn: olcDatabase=hdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
objectClass: olcHdbConfig
objectClass: olcPcacheDatabase
olcDatabase: hdb
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 200
olcDbIndex: objectClass eq
olcDbIndex: cn pres,eq,sub
I tried to add size.pr option to the Cache database but it seems to not be supported.
So does proxy cache support the use of paged results ?
Regards,
[cid:image001.gif@01CBF2E5.34FD28F0]
Laurent PERRIN
Service Infra aux Projets
Orange Applications for Business
SCE/OAB/DPO/DSPM/IOP
tel. +33 4 37 24 62 85
Mob : 07 84 12 78 79
laurent2.perrin(a)orange.com<mailto:laurent2.perrin@orange.com>
139 rue Vendôme 69006 Lyon
www.orange-business.com<http://www.orange-business.com/>
[cid:image002.gif@01CBF2E5.34FD28F0]
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
6 years, 5 months
Re: OpenLDAP with OpenSSL 1.1.0
by Quanah Gibson-Mount
--On Wednesday, October 05, 2016 11:43 AM -0700 Norm Green
<norm.green(a)gemtalksystems.com> wrote:
> I am trying to build OpenLDAP from source on Linux with OpenSSL 1.1.0. I
> first tried version 2.4.44 and found that didn't work due to the API
> changes in OpenSSL 1.1.0. I then filed ITS 8488 on the problem, which
> was quickly closed with the comment " Already supported in git master.
> Closing this ITS.".
>
> So I then got a copy of the git master and tried a build and it still
> fails in configure a follows:
>
> conftest.c:106: undefined reference to `SSL_library_init'
> ...
> configure:15618: result: no
> configure:15864: error: Could not locate TLS/SSL package
>
>
> This function is no longer present in OpenSSL 1.1.0 so it would appear
> the OpenLDAP configure script should be checking the version of OpenSSL
> before looking for the SSL_library_init symbol.
>
> Is this a known problem? Should I file a bug? Or is support for OpenSSL
> 1.1.0 known to be incomplete?
Follow up to ITS8353, noting that there is more to be done.
--Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 5 months
Re: User Import Problem with n-way multimaster setup
by Quanah Gibson-Mount
--On Wednesday, October 05, 2016 12:40 PM +0000 robert.lindner(a)delivion.de
wrote:
> Hi,
> I have a Problem importing a large batch of users into the following
> setup: Two Nodes of openldap running n-way multimaster replication with
> mdb backend, version is 2.4.44. Everything looks good, replication is
> working.
>
> Now I am trying to import a ldif file with 110362 Users to be added and
> 956419 group modify operations:
Hi Robert,
I would generally suggest using dynamic rather than static groups. You've
definitely found the downside to static groups -- They require an excessive
number of write ops that could otherwise be avoided. You may want to look
into how you're currently implementing your group data and re-adjust.
Hope that helps,
Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 5 months
OpenLDAP with OpenSSL 1.1.0
by Norm Green
I am trying to build OpenLDAP from source on Linux with OpenSSL 1.1.0.
I first tried version 2.4.44 and found that didn't work due to the API
changes in OpenSSL 1.1.0. I then filed ITS 8488 on the problem, which
was quickly closed with the comment " Already supported in git master.
Closing this ITS.".
So I then got a copy of the git master and tried a build and it still
fails in configure a follows:
conftest.c:106: undefined reference to `SSL_library_init'
...
configure:15618: result: no
configure:15864: error: Could not locate TLS/SSL package
This function is no longer present in OpenSSL 1.1.0 so it would appear
the OpenLDAP configure script should be checking the version of OpenSSL
before looking for the SSL_library_init symbol.
Is this a known problem? Should I file a bug? Or is support for
OpenSSL 1.1.0 known to be incomplete?
Norm Green
6 years, 5 months
Re: Syncrepl and missing entries
by Quanah Gibson-Mount
--On Wednesday, October 05, 2016 12:17 PM +0200 Thomas Hummel
<thomas.hummel(a)pasteur.fr> wrote:
> I'm answering some parts of my own question :
>
> as a matter of fact, the entry missing in my replica has an entryCSN
> lesser than the contestCSN. I guess that's the reason why it is not
> synchronised.
>
> Does that mean that, if for some reason, the replica gets out of sync in
> a similar manner, missing entries will never get synch'ed again unless -
> by "chance" - touched (modified) again (in which case they'll get a new
> entryCSN) ?
Correct
> Of course, I still don't undestand why this entry disapeared in the first
> place...
What release? There are known issues with syncrepl in various releases.
--Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 5 months
