Re: (ITS#7707) HDB very slow with _lots_ of aliases
by h.b.furuseth＠usit.uio.no
Yes. Aliases are a pain. Lots of aliases are not recommended.
They defeat your indexes: When you search with alias dereferencing
"always" or "search", the server must follow every alias in the
search scope to see if it leads to entries which should be returned.
This will not be fixed, such a change would be too invasive.
--
Hallvard
10 years
(ITS#7707) HDB very slow with _lots_ of aliases
by m.innocenti＠cineca.it
Full_Name: Marco Innocenti
Version: 2.4.36
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.186.19.81)
Hi,
I do administer a system which hosts a slapd instance (2.4.36) which is used
by one of our customer which use a tree with tens of thousand of aliases.
The backend is HDB.
If I do a search with alias dereferencing set to always using
"ou=1004,ou=studenti,o=uni,dc=uni,dc=it" as a base I do find the record I'm
looking for.
vm:~# time ldapsearch -x -H ldap://localhost:8501 -D 'cn=manager,dc=uni,dc=it'
-W -b ou=1004,ou=studenti,o=uni,dc=uni,dc=it uid=mario.rossi -a always | grep
\#
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=1004,ou=studenti,o=uni,dc=uni,dc=it> with scope subtree
# filter: uid=mario.rossi
# requesting: ALL
#
# mario.rossi, m, utenti, uni, uni.it
# search result
# numResponses: 2
# numEntries: 1
real 0m1.607s
user 0m0.000s
sys 0m0.000s
If I do the same search on the parent of the previously used base
("ou=studenti,o=uni,dc=uni,dc=it" vs "ou=1004,ou=studenti,o=uni,dc=uni,dc=it") I
do not get any record and no errors are logged.
vm:~# time ldapsearch -x -H ldap://localhost:8501 -D cn=manager,dc=uni,dc=it -W
-b ou=studenti,o=uni,dc=uni,dc=it uid=mario.rossi -a always
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=studenti,o=uni,dc=uni,dc=it> with scope subtree
# filter: uid=mario.rossi
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
real 0m5.301s
user 0m0.004s
sys 0m0.000s
10 years
(ITS#7706) RFE: contrib/slapo-lastbind extension
by marco.pizzoli＠gmail.com
Full_Name: Marco Pizzoli
Version: until 2.4.36
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.11.209.11)
This is another RFE for slapo-lastbind
I would appreciate being able to prevent some users from having their entry
updated/populated with the authTimestamp attribute.
I suppose this could be implemented with just the check of a specific attribute
(i.e. authTimestampLogging: FALSE) on the user entry.
Thanks in advance as usual
10 years
Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by hyc＠symas.com
openldap(a)semyon.org wrote:
> Full_Name: Semyon Chaichenets
> Version: 2.4.36
> OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (129.128.11.113)
>
>
> We have an issue whereby a paged-search operation causes slapd to segfault. At
> this point, I can only reproduce the issue on our production data - for which I
> cannot share coredumps. I am working on isolating the issue but would appreciate
> any help from openLDAP developers.
>
> The issue is triggered by the following search:
>
> ldapsearch -H ldap://ldaphost -b 'ou=people,dc=our,dc=org' -x -E pr=126/noprompt
> '(uid=m*)'
>
> We have ~59k entries starting matching uid=m*; the issue occurs unpredictably in
> the sense that it may or may not happen for filters matching other sets, but it
> can be reproduced reliably for any given filter/page size combination. On our
> setup, I could reproduce it for page-sizes 81,84,87,96,112,114,116,126.
>
> The issue is specific to back-mdb; backtrace points to dn2id.c:
>
> #0 0x00007f6d6a5ea6a1 in mdb_idscopes (op=0x7f695c110df0, isc=0x7f69692ca670)
> at ../../../../../servers/slapd/back-mdb/dn2id.c:738
> #1 0x00007f6d6a5e399b in mdb_search (op=0x7f695c110df0, rs=0x7f69692dba00)
> at ../../../../../servers/slapd/back-mdb/search.c:747
>
> [..]
>
> I would greatly appreciate any help you could give me with this problem.
If you backup the DB with slapcat and reload it on another server with
slapadd, can you still reproduce the fault on the copy?
>
>
> Best,
> Semyon
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years
Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by quanah＠zimbra.com
--On Monday, September 23, 2013 10:09 PM +0000 openldap(a)semyon.org wrote:
> Full_Name: Semyon Chaichenets
> Version: 2.4.36
> OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (129.128.11.113)
>
>
> We have an issue whereby a paged-search operation causes slapd to
> segfault. At this point, I can only reproduce the issue on our production
> data - for which I cannot share coredumps. I am working on isolating the
> issue but would appreciate any help from openLDAP developers.
Was this database created with OpenLDAP 2.4.36 back-mdb, or did it
originate with a previous release of OpenLDAP?
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years
(ITS#7705) mdb back-end segfaults sporadically with paged searches
by openldap＠semyon.org
Full_Name: Semyon Chaichenets
Version: 2.4.36
OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.128.11.113)
We have an issue whereby a paged-search operation causes slapd to segfault. At
this point, I can only reproduce the issue on our production data - for which I
cannot share coredumps. I am working on isolating the issue but would appreciate
any help from openLDAP developers.
The issue is triggered by the following search:
ldapsearch -H ldap://ldaphost -b 'ou=people,dc=our,dc=org' -x -E pr=126/noprompt
'(uid=m*)'
We have ~59k entries starting matching uid=m*; the issue occurs unpredictably in
the sense that it may or may not happen for filters matching other sets, but it
can be reproduced reliably for any given filter/page size combination. On our
setup, I could reproduce it for page-sizes 81,84,87,96,112,114,116,126.
The issue is specific to back-mdb; backtrace points to dn2id.c:
#0 0x00007f6d6a5ea6a1 in mdb_idscopes (op=0x7f695c110df0, isc=0x7f69692ca670)
at ../../../../../servers/slapd/back-mdb/dn2id.c:738
#1 0x00007f6d6a5e399b in mdb_search (op=0x7f695c110df0, rs=0x7f69692dba00)
at ../../../../../servers/slapd/back-mdb/search.c:747
[..]
I would greatly appreciate any help you could give me with this problem.
Best,
Semyon
10 years
Re: (ITS#7704) OpenLDAP-Max connection retry over issue
by quanah＠zimbra.com
--On Monday, September 23, 2013 7:37 AM +0000 saurabh.4091(a)gmail.com wrote:
> Full_Name: Saurabh Sudhir Bade
> Version: 0.9.8a
> OS: Windows server 2003
> URL:
> Submission from: (NULL) (213.42.50.245)
>
>
> Hi,
>
> We are using OpenLDAP to authenticate users accessing our web service.
> The LDAP is configured in TIBCO Activematrix Administrator where the
> services are deployed.
> We get the below mentioned error quite frequently.
> Error in authenticating credentials.Ldap Max connection retry over (3):
> localhost:9430: Connection refused: connect
> This happens because the connection pool is full and a new connection to
> LDAP is unavailable .
> Is there any way to increase the connection pool in LDAP? Please help me
> out. Please let me know if you need any further information on this issue.
Usage and configuration questions should be sent to the
openldap-technical(a)openldap.org email list. The ITS system is for
reporting bugs. This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years
(ITS#7704) OpenLDAP-Max connection retry over issue
by saurabh.4091＠gmail.com
Full_Name: Saurabh Sudhir Bade
Version: 0.9.8a
OS: Windows server 2003
URL:
Submission from: (NULL) (213.42.50.245)
Hi,
We are using OpenLDAP to authenticate users accessing our web service.
The LDAP is configured in TIBCO Activematrix Administrator where the services
are deployed.
We get the below mentioned error quite frequently.
Error in authenticating credentials.Ldap Max connection retry over (3):
localhost:9430: Connection refused: connect
This happens because the connection pool is full and a new connection to LDAP is
unavailable .
Is there any way to increase the connection pool in LDAP? Please help me out.
Please let me know if you need any further information on this issue.
Thanks
Regards
Saurabh
10 years
Re: (ITS#7703) mdb sync() issues vs. ACID
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: LMDB_0.9.8
> OS:
> URL:
> Submission from: (NULL) (81.191.45.35)
> Submitted by: hallvard
>
>
> mdb_env_sync() uses the wrong sync method when syncing a commit
> written with a different MDB_WRITEMAP setting in another MDB_env.
>
> Two processes with MDB_NOMETASYNC, each process doing every 2nd
> write txn, will sync each other's meta pages. If they have
> different MDB_WRITEMAPs, every meta page gets synced wrongly.
> This breaks durability of ACID.
Sounds like a doc issue. This can only arise if two separate processes are
using different configurations to access the same MDB environment. Most
applications will always use identical configurations to access their
databases, so this won't occur.
> There is a similar problem if a process crashes after writing
> the meta page but before sync succeeds, and mdb_env_open() then
> resets the lockfile to refer to the unsynced commit. Robust
> mutexes will introduce a similar problem without mdb_env_open.
>
>
> I'm not volunteering to figure out how to do this right, e.g. how
> do fsync/msync/FlushFileBuffers work on various OSes if the file
> descriptor or memory map is read-only, do we need to set a "need
> to sync" flag in the lockfile in this case for the first writer
> or write txn to obey?
>
> Another fix: Disable this scenario. Store the MDB_WRITEMAP
> setting in the lockfile when resetting it, even with MDB_RDONLY.
> Obey that flag rather than the writemap flag to mdb_env_open()
> when not resetting the lockfile. However, now a small program
> like mdb_stat can have disproportionate effect on another process
> which opens the env at the same time. Also nested txns need to
> work with MDB_WRITEMAP.
>
>
> For the crash case above and robust mutexes:
>
> Maybe mdb_env_open() should not modify me_txns->mti_txnid if it
> refers to the oldest meta page. That way the possibly unsynced
> commit will never be exposed unless the lockfile is removed.
> But next write txn must then reset the "hidden" metapage and sync
> before proceeding, similar to how mdb_env_write_meta() does at
> failure. Otherwise removing the lockfile would expose a meta
> page referring to data which may have been overwritten, e.g. by
> an mdb_abort()ed commit.
>
> Another variant would be to sync in mdb_env_open() when resetting
> the lockfile, or maybe an MDB_RDONLY env must set a "sync needed"
> flag.
Nothing to fix in code. Doc this as "don't do this." Nobody currently does it
anyway so it will have no impact.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years
