openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Re: mdb_dbi_open and threads
by Howard Chu 04 Aug '17

04 Aug '17

Hallvard Breien Furuseth wrote: > On 22. mai 2017 14:00, Howard Chu wrote: >> Muhammed Muneer wrote: >>> Hallvard wrote >> >>> "With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), >>> thread 1's prospect of using mdb_dbi_open() at all was lost." >>> >>> Yeah with both coexisting. Thats what I thought. > > Sorry, I should have said with _transactions_ #1 and #2 coexisting, > _transaction_ #1's prospect of using mdb_dbi_open() at all was lost. > Transaction #3 in thread #1 can use it if it stared after txn#2 ended. > > Anyway, just forget about being clever with DBIs. LMDB does not support > DBI cleverness, that's one of its trade-offs for speed and simplicity. Exactly. >> If you want to use dbi_open in multiple threads then put it in your own >> wrapper function, protected by a mutex. > > Wait, what? mdb_dbi_open() isn't coded to handle concurrent txns > calling it, regardless of any mutexes the caller has. In particular, > it does not use nor update the environment's numdbs, so the two > transactions could end up creating the same DBI for different DBs. Yes. This is only safe if you also close the dbi in the same txn that opened it. Which you are probably doing, if you are opening and closing on the fly. > >> Naturally you will also have to wrap dbi_close the same way. > > If we did support this, txn_commit() of the txn which used dbi_open() > would also need the mutex. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: mdb broken under OpenBSD
by Howard Chu 04 Aug '17

04 Aug '17

Paul B. Henson wrote: > I was interested in using openldap under OpenBSD; they currently have > mdb disabled as they say it is broken. That OS lacks a unified buffer > cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but > supposedly theoretically it should work with that. I tried running the > mdb tests, and it immediately segfaults: > > Program terminated with signal 11, Segmentation fault. > > 2773 flags |= env->me_flags & MDB_WRITEMAP; > > It looks like mdb_txn_begin is being passed a NULL env? I haven't started > poking around yet to see why that might be, but I thought I'd just toss this > out there in case an expert had a thought before I spent a lot of time on > it :). Thanks... OpenBSD's lack of a unified buffer cache is a pretty glaring deficiency, yes. Have to say, since getting nowhere discussing that feature with them, I personally have written off supporting it. For the trace you're showing, you'll have to debug the slapadd invocation and find out why env is NULL. Also use current (2.4.45) source, at least. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

mdb broken under OpenBSD
by Paul B. Henson 03 Aug '17

03 Aug '17

I was interested in using openldap under OpenBSD; they currently have mdb disabled as they say it is broken. That OS lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but supposedly theoretically it should work with that. I tried running the mdb tests, and it immediately segfaults: Program terminated with signal 11, Segmentation fault. 2773 flags |= env->me_flags & MDB_WRITEMAP; It looks like mdb_txn_begin is being passed a NULL env? I haven't started poking around yet to see why that might be, but I thought I'd just toss this out there in case an expert had a thought before I spent a lot of time on it :). Thanks... #0 0x000016210db057c5 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x16210df6fec0) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/../../../libraries/libl mdb/mdb.c:2773 txn = (MDB_txn *) 0xf ntxn = (MDB_ntxn *) 0x0 rc = 0 size = 0 tsize = 32639 #1 0x000016210db224df in mdb_tool_entry_put (be=0x1623ccbdd200, e=0x16235a80c008, [47/9401] text=0x7f7ffffeeb90) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/tools.c:624 rc = 0 mdb = (struct mdb_info *) 0x1623c3580000 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = { rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0x0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\0' <repeats 255 times>} __func__ = "mdb_tool_entry_put" #2 0x000016210dac8329 in slapadd (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/slapadd.c:456 textbuf = '\0' <repeats 255 times> textlen = 256 erec = {e = 0x16235a80c008, lineno = 1, nextline = 18} bvtext = {bv_len = 256, bv_val = 0x7f7ffffeebd0 ""} thr = 0x16210dd8cd78 id = 140187732470848 prev = (Entry *) 0x0 ldifrc = 1 rc = 0 stat_buf = {st_mode = 4294896512, st_dev = 32639, st_ino = 140187732470584, st_nlink = 990767968, st_uid = 5667, st_gid = 0, st_rdev = 0, st_atim = {tv_sec = 179931522, tv_nsec = 48}, st_mtim = {tv_sec = 24342436749856, tv_nsec = 24341375494144}, st_ctim = { tv_sec = 24343378665241, tv_nsec = 140187732470664}, st_size = 0, st_blocks = 140187732470664, st_blksize = 990767968, st_flags = 5667, st_gen = 0, __st_birthtim = {tv_sec = 179915312, tv_nsec = 48}} #3 0x000016210da02d7a in main (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/main.c:664 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 8 waitfds = {331804096, 5667} g_argc = 8 g_argv = (char **) 0x7f7ffffeee58 configfile = 0x0 configdir = 0x0 serverName = 0x7f7ffffef122 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x16210ddb6ec5 "" l = 1 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __func__ = "main"

1 0

Re: searching userPassword value
by Howard Chu 03 Aug '17

03 Aug '17

Quanah Gibson-Mount wrote: > --On Wednesday, August 02, 2017 6:28 PM -0400 David Magda > <dmagda(a)ee.ryerson.ca> wrote: > >> Doing an "ldapsearch […] '(userpassword={SHA}*'" gets zero results. >> >> Thanks for any info. > > userPassword is base64 encoded, so no, you can't do that. False. The base64 encoding only happens in the ldapsearch tool just before it prints the result on stdout. The userPassword schema definition has no substring matching rule. And you should already know to check the schema definition for questions like this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: searching userPassword value
by Quanah Gibson-Mount 03 Aug '17

03 Aug '17

--On Wednesday, August 02, 2017 6:28 PM -0400 David Magda <dmagda(a)ee.ryerson.ca> wrote: > Doing an "ldapsearch […] '(userpassword={SHA}*'" gets zero results. > > Thanks for any info. userPassword is base64 encoded, so no, you can't do that. You could find all the values, and then decode them. Or you could decode a specific value for a given user to see what sort of hash it is using. I'd probably use perl or python. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

searching userPassword value
by David Magda 02 Aug '17

02 Aug '17

Hello, Is there a way to search the value of the userPassword attribute? Specifically I’m hoping to determining to whether it begins with {SHA}, {CRYPT}, etc. Using the (olc)rootdn account is fine; it doesn’t have to be a regular user as this would be a rare/manual operational need. Doing an “ldapsearch […] ‘(userpassword={SHA}*'" gets zero results. Thanks for any info. Regards, David

1 0

Blacklists of simple values in LDAP attribute constraints overlay?
by Florian Best 02 Aug '17

02 Aug '17

Hello, I am searching for a way to add an LDAP constraint on attributes which prevents setting specific values. For example, I want to prevent that the attribute "uid" is equal to (case insensitive) "foo" or "bar". Using the manpage from https://linux.die.net/man/5/slapo-constraint it seems not possible, I tried a lot of things like: constraint_attribute uid set "this/uid & ([foo])" constraint_attribute uid set "this/uid & [foo]" constraint_attribute uid uri ldap:///dc=school,dc=local?forbidden?sub?(objectClass=forbiddenUsernames) constraint_attribute uid regex ^[^f][^o][^o]*$ Even if they were working (they don't) I needed to reverse the whole constraint because this would only allow me to add a whitelist while I want to add a blacklist. (Best would be If I could just add a "!" before the attribute contsraint.) I hope there is something which could help me. Best regards Florian -- Florian Best Open Source Software Engineer Univention GmbH be open Mary-Somerville-Str.1 28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 best(a)univention.de http://www.univention.de Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876

2 6

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 27 Jul '17

27 Jul '17

--On Friday, June 30, 2017 8:32 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: >> And what does the master say? >> > > same thing: > > slapd[38004]: conn=30116 op=3 SEARCH RESULT tag=101 err=53 nentries=0 > text=consumer state is newer than provider! It sounds like your replica was not configured correctly initially and self-generated its own CSN that is newer than the one on the provider. It would be interesting to make a modification on the provider so that its CSN is updated (and thus has one newer than on the consumer). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

[Q] "selective" ACL
by Zeus Panchenko 26 Jul '17

26 Jul '17

hi, I'm trying to configure a not complex (as I believe) ACL ... but have some difficulties I have two posixGroup groups cn=admins,ou=group,dc=foo cn=coadmins,ou=group,dc=foo my users resides in ou=People,dc=foo so, in subtree ou=People,dc=foo I need to allow anything to admins (and it is not difficult of course) for example this works for me: access to dn.subtree="ou=People,dc=foo" by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage by self write by users read by * break but in addition I need to allow my coadmins to do the same things except manipulations upon the objects which belong to admins ( ...anyobject,uid=adminuser,ou=People,dc=foo ) so, the question is: how? (if it is possible at all) :( please, advise -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

2 2

Sometimes openldap messages are logged in incorrect order
by Amit 26 Jul '17

26 Jul '17

Hello, I find sometimes order of event in openldap logs as: BIND RESULT ACCEPT SRCH base SRCH attr= SEARCH RESULT closed Configured rsyslog as: $template myTemplate,"%timegenerated:::date-rfc3339% %timereported:::date-rfc3339% %msg%\n" local4.* /var/log/rsyslog.log;myTemplate But I believe correct order should be: Accept Bind result srch base unbind closed What cant be the reason, is it related to openldap logging mechanism or Logger rsyslog. -- Thanks Amit

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical