openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Question about automounting nfs directories within ldap
by Bänsch, Christian (TF) 12 Oct '17

12 Oct '17

Dear Community, thank you for your help to made my ldap configuration runnable and the login for users working. Now I have the next question about automounting nfs directories. In my /etc/exports I have several directories /export/home 10.188.114.0/25(fsid=0,rw,sync,root_squash,secure,no_subtree_check) /export/software/linux 10.188.114.0/25(rw,root_squash,sync,subtree_check,secure) /export/calculate 10.188.114.0/25(rw,root_squash,sync,no_subtree_check) I want to export when the ldap user is going to login. But when I do this, I´ll get those error messages. Oct 9 09:59:13 fautm89 automount[13131]: attempting to mount entry /home/iwtm009 Oct 9 09:59:13 fautm89 automount[13131]: >> mount.nfs: access denied by server while mounting fautm89.ltm.uni-erlangen.de:/export/home/iwtm009 Oct 9 09:59:13 fautm89 automount[13131]: mount(nfs): nfs: mount failure fautm89.ltm.uni-erlangen.de:/export/home/iwtm009 on /home/iwtm009 Oct 9 09:59:13 fautm89 automount[13131]: failed to mount /home/iwtm009 Oct 9 10:00:01 fautm89 automount[13131]: attempting to mount entry /local/calculate Oct 9 10:00:01 fautm89 automount[13131]: >> mount.nfs: access denied by server while mounting fautm89.ltm.uni-erlangen.de:/export/calculate Oct 9 10:00:01 fautm89 automount[13131]: mount(nfs): nfs: mount failure fautm89.ltm.uni-erlangen.de:/export/calculate on /local/calculate Oct 9 10:00:01 fautm89 automount[13131]: failed to mount /local/calculate Oct 9 10:00:14 fautm89 automount[13131]: attempting to mount entry /local/linux Oct 9 10:00:14 fautm89 automount[13131]: >> mount.nfs: access denied by server while mounting fautm89.ltm.uni-erlangen.de:/export/software/linux Oct 9 10:00:14 fautm89 automount[13131]: mount(nfs): nfs: mount failure fautm89.ltm.uni-erlangen.de:/export/software/linux on /local/linux Oct 9 10:00:14 fautm89 automount[13131]: failed to mount /local/linux When I do e.g. a ls -la in /home on the server, I get drwx------ 79 iwtm009 tm 4096 Aug 22 13:15 iwtm009/ on the client I get dr-xr-xr-x 2 root root 0 Oct 9 09:47 iwtm009 Should I have to adjust this in slapd configuration or am I just blind to see it? -- Thank you in advance and best regards, Christian

2 2

Re: Replication error
by Quanah Gibson-Mount 12 Oct '17

12 Oct '17

--On Tuesday, October 10, 2017 6:39 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > binddn="uid=repuser,dc=my,dc=domain,dc=hu" > Anyway - how can I solve this problem? Your uid=repuser,dc=my,dc=domain,dc=hu user does not have "read" access on the userPassword attribute. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: make test seg fault related to libc
by Quanah Gibson-Mount 12 Oct '17

12 Oct '17

--On Wednesday, October 11, 2017 1:02 PM -0700 Scott Classen <sclassen(a)lbl.gov> wrote: ># ulimit -a Hm, well, that doesn't appear to be it. :/ You might look at the testrun logs and see what slapd is logging when it dies as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: make test seg fault related to libc
by Quanah Gibson-Mount 11 Oct '17

11 Oct '17

--On Wednesday, October 11, 2017 10:44 AM -0700 Scott Classen <sclassen(a)lbl.gov> wrote: > Hello, > > I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the > following configuration: I've seen this happen when a ulimit value was unreasonably small. Check the limits on -m or -v perhaps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

make test seg fault related to libc
by Scott Classen 11 Oct '17

11 Oct '17

Hello, I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the following configuration: ./configure --enable-bdb=no --enable-hdb=no --enable-mdb --with-tls=openssl --enable-spasswd --enable-syslog --enable-modules --enable-cleartext --enable-overlays --enable-accesslog --enable-auditlog --with-threads --enable-shared --enable-ldap --enable-monitor --enable-deref --enable-slapd --enable-ppolicy --enable-memberof When I run make test I receive numerous segmentation faults: output from make test: > ./scripts/test028-idassert: line 252: 28923 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 > >>>>> test028-idassert completed OK for mdb. > > >>>>> Starting test029-ldapglue for mdb... > running defines.sh > ### This test requires the ldap backend and glue overlay. > ### If available, and explicitly requested, it can use SASL bind; > ### note that SASL must be properly set up, and the requested > ### mechanism must be available. Define SLAPD_USE_SASL={yes|<mech>}, > ### with "yes" defaulting to DIGEST-MD5 to enable SASL authc[/authz]. > Using proxyAuthz with simple authc... > Running slapadd to build slapd database... > Starting local slapd on TCP/IP port 9011... > Starting remote slapd 1 on TCP/IP port 9012... > Starting remote slapd 2 on TCP/IP port 9013... > Using ldapsearch to check that slapd is running... > Using ldapsearch to check that slapd is running... > Using ldapsearch to check that slapd is running... > Testing ldapsearch as uid=bjorn,ou=People,dc=example,dc=com for "dc=example,dc=com"... > Filtering ldapsearch results... > Filtering original ldif used to create database... > Comparing filter output... > Testing ldapsearch as anonymous for "dc=example,dc=com"... > Filtering ldapsearch results... > Filtering original ldif used to create database... > Comparing filter output... > >>>>> Test succeeded > ./scripts/test029-ldapglue: line 222: 28992 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 > ./scripts/test029-ldapglue: line 222: 28994 Segmentation fault (core dumped) $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 > ./scripts/test029-ldapglue: line 222: 28996 Segmentation fault (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 > >>>>> test029-ldapglue completed OK for mdb. In /var/log/messages: > Oct 11 09:31:42 www kernel: slapd[9039]: segfault at 1100fffff7 ip 00007febd7a2f4dc sp 00007ffe832541f8 error 4 in libc-2.17.so[7febd79af000+1b8000] > Oct 11 09:31:42 www kernel: slapd[8997]: segfault at 1100fffff7 ip 00007f48923e44dc sp 00007ffec5a22658 error 4 in libc-2.17.so[7f4892364000+1b8000] > Oct 11 09:31:42 www kernel: slapd[8975]: segfault at 1100fffff7 ip 00007f01a727d4dc sp 00007ffd9a127698 error 4 in libc-2.17.so[7f01a71fd000+1b8000] > Oct 11 09:31:42 www abrt-hook-ccpp: Process 8975 (slapd) of user 0 killed by SIGSEGV - ignoring (repeated crash) > Oct 11 09:31:42 www abrt-hook-ccpp: Process 9039 (slapd) of user 0 killed by SIGSEGV - dumping core > Oct 11 09:31:42 www abrt-hook-ccpp: Process 8997 (slapd) of user 0 killed by SIGSEGV - dumping core I don't see any obvious problems with the linked libraries: [me@here openldap-2.4.45]# ldd servers/slapd/slapd linux-vdso.so.1 => (0x00007ffd98751000) libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f930d78b000) libicuuc.so.50 => /lib64/libicuuc.so.50 (0x00007f930d412000) libicudata.so.50 => /lib64/libicudata.so.50 (0x00007f930be3d000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f930bc20000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f930b9ae000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f930b54c000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f930b332000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f930b116000) libc.so.6 => /lib64/libc.so.6 (0x00007f930ad52000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f930ab4e000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f930a846000) libm.so.6 => /lib64/libm.so.6 (0x00007f930a543000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f930a32d000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f930a0f6000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f9309ea8000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f9309bc0000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f93099bc000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f9309788000) libz.so.1 => /lib64/libz.so.1 (0x00007f9309572000) /lib64/ld-linux-x86-64.so.2 (0x000055eefaf24000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f930936e000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f9309160000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f9308f5c000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f9308d34000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f9308ad2000) Any advice or suggestions would be welcome. Regards, Scott

1 0

Re: Upgrade from 2.4.40 to 2.4.44
by Quanah Gibson-Mount 11 Oct '17

11 Oct '17

--On Friday, September 15, 2017 9:18 AM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > IIRC slapcat doesn't work in this case, because it fails to initialize > the ppolicy module. > > The linked CentOS and RHEL bugs recommend downgrading slapd to the > previously working version and using ldapmodify. Yeah, that's ugly :/ Another reason we really need to get slapmodify out, and some way to execute it with an option to not load modules or similar. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

Replication error
by Ervin Hegedüs 10 Oct '17

10 Oct '17

Hi, I (think I) setting up completly a master-slave replication. The replication user can access from the slave (ldapsearch works). Here is the config, what I added on slave: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://master:636/ bindmethod=simple binddn="uid=repuser,dc=my,dc=domain,dc=hu" credentials=SECRET searchbase="dc=my,dc=domain,dc=hu" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 tls_cacert=/etc/ldap/CAcert.pem tls_cert=/etc/ldap/slave_cert.pem tls_key=/etc/ldap/slave_key.pem tls_reqcert=demand And now I found these lines in syslog: Oct 10 17:36:40 open-ldap2 slapd[4640]: Entry (cn=admin,dc=my,dc=domain,dc=hu): object class 'simpleSecurityObject' requires attribute 'userPassword' Oct 10 17:36:40 open-ldap2 slapd[4640]: null_callback : error code 0x41 Oct 10 17:36:40 open-ldap2 slapd[4640]: syncrepl_entry: rid=001 be_add cn=admin,dc=my,dc=domain,dc=hu failed (65) Oct 10 17:36:41 open-ldap2 slapd[4640]: do_syncrepl: rid=001 rc 65 retrying (4 retries left) I think this occures, because the cn=admin,dc=... user is a simpleSecurityObject, and could't access the userPassword from the ldapsearch - or not :). Anyway - how can I solve this problem? Thanks, a.

1 0

Preauth Issue with SASL-Passthrough and Kerberos Backend
by Ulrich Tehrani 06 Oct '17

06 Oct '17

Hi all, i setup an openldap server which is used as MIT-Kerebros backend. User-Principals have - besides the kerberos attributes - appropriate objectclasses (e.g. simplesecurityObject, organizationalRole) to make also a simple authentication with the attribut userpassword possible. To consolidate both credentials i made a setup of SASL-Pasthrough with backend Kerberos. So i set the value of the userpassword attribut to. {SASL}<user>@<realm> and made the required configurations for the saslauthd. With this configuration all kind of authentications will use the kerberos-password. I made various tests but there seems to be an issue with preauthentication in openldap. I got the follwoing result: =>testsaslauthd is always working if the preauth flag is on or off =>ldapsearch -x is only working with preauth-flag disabled. => It makes no difference if MIT Kerberos use its normal backend Keep in mind: For clear testing condtions saslauthd-caching has to be disabled ! Don't use the -c Option in saslauthd - otherwise it could happen that your ldapsearch -x is working because you had success with a former testsaslauthd-command ! Has someone a similar setup which is working with enabled preauth ? Or does someone know if this is supported or not ? I use LDAP 2.4.44 with cyrus-sasl-2.1.23. Thanks in advance. Kind regards Uli -- =================================== Ulrich Tehrani Am Ulrichshof 19 79189 Bad Krozingen

2 1

Re: Can't get lmdb to build on FreeBSD 12
by Howard Chu 04 Oct '17

04 Oct '17

Russell Haley wrote: > Hi, > > Sorry for the silly question, but I've stumped myself and my C is > weak. Normally lmdb builds fine without issue on most of the platforms > I try (Debian Jessie, FreeBSD 10.3 & 12), but it's stopped compiling > on my TrueOS box, which is FreeBSD 12. I've tried gcc and clang 4.0 > and 3.9. Try using GNU make. It looks like whatever make you're using doesn't have the proper default build rules. > ------------------------ > > russellh@prescott:~/Git/lmdb/libraries/liblmdb% make > cc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -Wuninitialized -v mdb_stat.c -o mdb_stat > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/cc" -cc1 -triple x86_64-unknown-freebsd12.0 -emit-obj > -disable-free -main-file-name mdb_stat.c -mrelocation-model static > -mthread-model posix -mdisable-fp-elim -masm-verbose > -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v > -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 > -debugger-tuning=gdb -resource-dir /usr/bin/../lib/clang/4.0.0 -O2 -W > -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized > -fdebug-compilation-dir /usr/home/russellh/Git/lmdb/libraries/liblmdb > -ferror-limit 19 -fmessage-length 237 -pthread -fobjc-runtime=gnustep > -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o > /tmp/mdb_stat-852384.o -x c mdb_stat.c > clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target > x86_64-unknown-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/bin/../lib/clang/4.0.0/include > /usr/include > End of search list. > "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 > --hash-style=both --enable-new-dtags -o mdb_stat /usr/lib/crt1.o > /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/mdb_stat-852384.o > -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc > --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > /tmp/mdb_stat-852384.o: In function `main': > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:104: > undefined reference to `mdb_env_create' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:106: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:111: > undefined reference to `mdb_env_set_maxdbs' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:114: > undefined reference to `mdb_env_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:116: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:121: > undefined reference to `mdb_env_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:122: > undefined reference to `mdb_env_info' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:136: > undefined reference to `mdb_reader_list' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:139: > undefined reference to `mdb_reader_check' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:141: > undefined reference to `mdb_reader_list' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:147: > undefined reference to `mdb_txn_begin' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:149: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:257: > undefined reference to `mdb_env_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:160: > undefined reference to `mdb_cursor_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:162: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:165: > undefined reference to `mdb_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:171: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:171: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:199: > undefined reference to `mdb_cursor_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:203: > undefined reference to `mdb_dbi_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:205: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:209: > undefined reference to `mdb_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:(.text+0x5d6): > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:255: > undefined reference to `mdb_txn_abort' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:221: > undefined reference to `mdb_cursor_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:223: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:226: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:234: > undefined reference to `mdb_dbi_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:239: > undefined reference to `mdb_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:245: > undefined reference to `mdb_dbi_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:226: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:247: > undefined reference to `mdb_cursor_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:253: > undefined reference to `mdb_dbi_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:241: > undefined reference to `mdb_strerror' > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop. > make: stopped in /usr/home/russellh/Git/lmdb/libraries/liblmdb > > ---------------------------------- > The full output is here with uname, git status and compiler info: > http://termbin.com/io9d > > Any help would be grand. > > Thanks, > Russ > > -- -- 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 2

Re: lmdb as a Lua database
by Russell Haley 04 Oct '17

04 Oct '17

Brilliant. May I ping you for more information? I'm tightly coupled to my current toolchain but will use this for reference. Russ On Wed, Oct 4, 2017 at 9:21 AM, Леонид Юрьев <leo(a)yuriev.ru> wrote: > take a look at https://github.com/PositiveTechnologies/libfpta > > regads. > > > 2017-10-04 9:20 GMT+03:00 Russell Haley <russ.haley(a)gmail.com>: >> On Tue, Oct 3, 2017 at 11:19 PM, Russell Haley <russ.haley(a)gmail.com> wrote: >>> Hi, >>> >>> So I'm using LMDB to create a simple 'database' system for lua that >>> will allow me to directly serialize and store lua table data. So far I >>> have used the wonderful lmdb wrapper lightningmdb and created a simple >>> API to hide some of the mechanisms. >>> >>> Honestly, your API is so well thought out, I'm doing a disservice by >>> removing a lot of the powerful features. However, I press ahead and >>> beg forgiveness. :) >>> >>> I have two questions: >>> >>> 1) There is a simplified vs cursor API. I am starting to suspect that >>> the simplified functions are just basic wrappers around the cursor >>> API? I ask because if this is the case, I could just remove my support >>> for the simplified API and only have to support one set of functions. >>> >>> 2) The key lookup is blazing fast (so awesome, this thing is going to >>> smoke!). I wanted to create a way of indexing the data elements within >>> the database by allowing users to create lua functions that parse the >>> lua table values. >>> --a basic table that would be serialized into a lmdb database called t1 >>> t1 = { >>> 1={col_a="test",col_b="item1"}, >>> 2={col_a="not-a-test",col_b="item2"}, >>> 3={col_a="test",col_b="item3"} >>> } >>> >>> --The function that would be called per-row to create an index. >>> local function(k,v) >>> >>> return v.col_a, k >>> end >>> >>> The idea would be to use the dupsort feature to create an 'index' >>> database with data structured as: >>> >>> not-a-test, 2 >>> test, 1 >>> test, 3 >> >> Sorry, hit send in gmail by accident. Anyway, the idea is to use the >> dupsort feature to create indexes. Is this feasible? Any input or >> direction would be fantastic. >> >> Thanks! >> Russ >>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical