openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Re: [EXT] Slapd unexpectedly shutdown
by Kevin Olbrich 08 Apr '20

08 Apr '20

Am Di., 7. Apr. 2020 um 23:18 Uhr schrieb Quanah Gibson-Mount <quanah(a)symas.com>: > > > > --On Tuesday, April 7, 2020 11:36 PM +0200 Kevin Olbrich <ko(a)sv01.de> wrote: > > > Def. ANOM_ABEND: Triggered when a processes ends abnormally (with a > > signal that could cause a core dump, if enabled). > > > > Looks like it's actually crashing but I don't think it's because of > > "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" > > as I can see multiple lines before the crash. > > > > Is it possible that Slapd crashed if it tries to proxy data to a node > > while it shuts down? Maybe a special case when bind was successful but > > query failes? > > Hi Kevin, > > What OpenLDAP Release are you running? I ask, because there was a fix that > went into OpenLDAP 2.4.49 specifically for a crasher with back-ldap and > controls: > > <https://bugs.openldap.org/show_bug.cgi?id=9076> > > Regards, > Quanah > My version is 2.4.49+dfsg-2~bpo10+1 (buster-backports). Should be in there I think. I've now included ppolicy.schema to solve the issue. Tomorrow I will try if the issue is still present. Thanks for your input! Regards Kevin > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

3 3

Re: [EXT] Slapd unexpectedly shutdown
by Quanah Gibson-Mount 07 Apr '20

07 Apr '20

--On Tuesday, April 7, 2020 11:36 PM +0200 Kevin Olbrich <ko(a)sv01.de> wrote: > Def. ANOM_ABEND: Triggered when a processes ends abnormally (with a > signal that could cause a core dump, if enabled). > > Looks like it's actually crashing but I don't think it's because of > "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" > as I can see multiple lines before the crash. > > Is it possible that Slapd crashed if it tries to proxy data to a node > while it shuts down? Maybe a special case when bind was successful but > query failes? Hi Kevin, What OpenLDAP Release are you running? I ask, because there was a fix that went into OpenLDAP 2.4.49 specifically for a crasher with back-ldap and controls: <https://bugs.openldap.org/show_bug.cgi?id=9076> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

macbookair configuration to connect to network personal folder
by Arnaud Gymnase 07 Apr '20

07 Apr '20

Hello all, I've a procect for a school to authenticate macbooks to an OpenLDAP Server. The server part has been build using a ClearOS system (centos) with OpenLDAP. I then configured the macbook to authentify to my OpenLDAP server to open a session and this works fine. The next thing I'd like consist of configuring an automatic connexion to the personnal network folder. I tried to use the attribute "NFSHomeDirectory" in several ways but this didn't worked. Do you have an idea on which attribute could I use to connect my user (sambaHomepath ?) and maybe how could I retrive my username/password to authenticate to it ? Thanks to all :)

1 0

Antw: [EXT] Slapd unexpectedly shutdown
by Ulrich Windl 07 Apr '20

07 Apr '20

>>> Kevin Olbrich <ko(a)sv01.de> schrieb am 06.04.2020 um 23:00 in Nachricht <15853_1586208569_5E8B9F39_15853_1729_1_CA+gLzy8cpURhV3Ti41im3Z=vRcq2VoEd0n_E+P8 EKnfN4=wPQ(a)mail.gmail.com>: > Hi! > > I'm experiencing an issue with Slapd 2.4.49 on Debian Buster. > I use Slapd as a proxy / lb with two AD nodes behind it. > > If I reboot one of the AD nodes, everything is fine. As soon as I > reboot the seconds one (while the first is back and available), > OpenLDAP shuts down immediately: > Apr 06 22:03:33 ldap-lb1.ldap.example.com slapd[22140]: Stopping > OpenLDAP: slapd. > Apr 06 22:03:33 ldap-lb1.ldap.example.com systemd[1]: slapd.service: > Succeeded. > > There is no traffic during this time and it matches the exact time > when node two is down. > > Debian still uses an init script for slapd but I did not find anything > interesting in it. > > Is there a config setting that I missed in the docs that explains this > behavior? > As it's not crashing, HA in systemd won't catch this issue. Start some tracing and logging I'd suggest. Something ust be triggering that, and you must capture the "something" before you can get a solution. > > Kind regards > Kevin

3 2

front end for openldap
by paulo bruck 07 Apr '20

07 Apr '20

Hi All I have been using openldap for many years and I would like to thanks to all . Is there a framewok to use with openldap as backend? Preferably based on Python 80) I look at django-ldapdb but project is almost dead and does not have all that I need. Flask has only autentication..8( Any ideas? thanks in advanced and again nice work 80)) -- Paulo Ricardo Bruck consultor tel 011 3596-4881/4882 011 98140-9184 (TIM) http://www.contatogs.com.br http://www.protejasuarede.com.br gpg AAA59989 at wwwkeys.us.pgp.net

5 5

Antw: [EXT] LMDB: sync'ing to disk and flash wear
by Ulrich Windl 07 Apr '20

07 Apr '20

>>> Alberto Mardegan <mardy(a)users.sourceforge.net> schrieb am 06.04.2020 um 08:44 in Nachricht <10444_1586183585_5E8B3DA1_10444_128_1_5863f87e-d26b-2943-9302-bf5bfc270e71@user .sourceforge.net>: > Hi all! > I'm trying to understand the impact that a LDMB database will have on > the flash wear of an embedded device. > > In order to minimize disk writes, I'm keeping a DB open all the time, > and I'd like to have the changes written into the physical storage only > when mdb_env_sync() is called (near the end of my process lifetime). > I'm opening the DB with the MDB_NOSYNC | MDB_WRITEMAP | MDB_NOMETASYNC > flags, and if I strace the executable I see that lmdb behaves as > expected: no writes happen until I call mdb_env_sync(). > > However, the writes end up to the physical storage anyway, because the > kernel reserves the right of flushing changes of an mmap'ed file to disk > at any time (as per the documentation of MAP_SHARED). I don't exactly > know if this happens because some other process is calling sync(), or > which criteria the kernel follows, but as a matter of fact a write > happens every few seconds. > > Looking at the code, it looks like it's impossible to instruct LMDB to > use MAP_PRIVATE without modifying the code. But before exploring that > solution, I'd like to be sure I understand the real behaviour of LMDB. Doesn't MAP_PRIVATE imply that the map can't be written to disk? > > Do I understand correctly, that if during the lifetime of my process the > same key is assigned different values, with mdb_txn_commit() being > called each time, the same addresses in the shared memory area will be > changed several times (leading to unnecessary re-writes of the same area > of the flash storage)? Or is LMDB only operating in "append" mode, so > that it tries to avoid writing the same area twice? I think no DB system can implement a commit with just one write. Why not put your DB im a RAM disk and then rsync to flash when done? Regards, Ulrich > > Thanks in advance for any answer, > Alberto > > -- > http://www.mardy.it - Geek in un lingua international

1 0

LMDB: sync'ing to disk and flash wear
by Alberto Mardegan 07 Apr '20

07 Apr '20

Hi all! I'm trying to understand the impact that a LDMB database will have on the flash wear of an embedded device. In order to minimize disk writes, I'm keeping a DB open all the time, and I'd like to have the changes written into the physical storage only when mdb_env_sync() is called (near the end of my process lifetime). I'm opening the DB with the MDB_NOSYNC | MDB_WRITEMAP | MDB_NOMETASYNC flags, and if I strace the executable I see that lmdb behaves as expected: no writes happen until I call mdb_env_sync(). However, the writes end up to the physical storage anyway, because the kernel reserves the right of flushing changes of an mmap'ed file to disk at any time (as per the documentation of MAP_SHARED). I don't exactly know if this happens because some other process is calling sync(), or which criteria the kernel follows, but as a matter of fact a write happens every few seconds. Looking at the code, it looks like it's impossible to instruct LMDB to use MAP_PRIVATE without modifying the code. But before exploring that solution, I'd like to be sure I understand the real behaviour of LMDB. Do I understand correctly, that if during the lifetime of my process the same key is assigned different values, with mdb_txn_commit() being called each time, the same addresses in the shared memory area will be changed several times (leading to unnecessary re-writes of the same area of the flash storage)? Or is LMDB only operating in "append" mode, so that it tries to avoid writing the same area twice? Thanks in advance for any answer, Alberto -- http://www.mardy.it - Geek in un lingua international

2 1

Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap weird behavior
by "POISSON Frédéric" 06 Apr '20

06 Apr '20

Hello, I'm doing a OpenLDAP test with a master/slave replication configuration including ppolicy overlay. I would like to enable password change from the slave replica with chain overlay, in order to validate the ppolicy olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to master with SASL External authentication with client certificate. The client certificate correspond to a user DN entry with "manage" rights on the master server (the same used for the replication). This user DN has authzTo attribute in order to match the correct PROXYAUTHZ request from its dn to user DN. All of this configuration works on replica when i do first a failed authentication (err=49) on replica. The pwdFailureTime value is updated on the DN entry from replica to slave normally. I'm also able to do after some self entry update on some attribute such as password or others from replica to master. But the weird behavior is that i need to run first an failed authentication, otherwise if i try to change attribute on the slave server, it respond an err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The only way to retrieve correct behavior is to restart slapd, and redo one failed authentication first. It seems that the chain overlay do not connect the master server at startup Do you have any ideas why i have this behavior ? I'm using a 2.4.49 build of openldap, and inside logs on master server i see that the slave use the same connection. Here is the LDIF change and configuration on my replica : dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldaps://valid7-lab-ldap1.tld olcDbIDAssertBind: bindmethod=sasl saslmech=external starttls=no tls_cert="/usr/local/openldap/etc/openldap-valid7/tls/db1_rid001_cert.pem" tls_key="/usr/local/openldap/etc/openldap-valid7/tls/db1_rid001_key.pem" tls_cacert="/usr/local/openldap/etc/openldap-valid7/tls/cacert.pem" tls_reqcert=demand tls_crlcheck=none mode=self olcDbRebindAsUser: TRUE dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcUpdateRef olcUpdateRef: ldaps://valid7-lab-ldap1.tld - dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config changetype: modify replace: olcPPolicyForwardUpdates olcPPolicyForwardUpdates: TRUE - Here is LDIF change on my master : dn: cn=config changetype: modify replace: olcAuthzPolicy olcAuthzPolicy: to - Thanks in advance for your reply -- Frederic Poisson

2 1

Slapd unexpectedly shutdown
by Kevin Olbrich 06 Apr '20

06 Apr '20

Hi! I'm experiencing an issue with Slapd 2.4.49 on Debian Buster. I use Slapd as a proxy / lb with two AD nodes behind it. If I reboot one of the AD nodes, everything is fine. As soon as I reboot the seconds one (while the first is back and available), OpenLDAP shuts down immediately: Apr 06 22:03:33 ldap-lb1.ldap.example.com slapd[22140]: Stopping OpenLDAP: slapd. Apr 06 22:03:33 ldap-lb1.ldap.example.com systemd[1]: slapd.service: Succeeded. There is no traffic during this time and it matches the exact time when node two is down. Debian still uses an init script for slapd but I did not find anything interesting in it. Is there a config setting that I missed in the docs that explains this behavior? As it's not crashing, HA in systemd won't catch this issue. Kind regards Kevin

1 0

Re: NetworkRadius CentOS pkg uses openldap-ltb which conflict with symas-openldap
by Dave Macias 02 Apr '20

02 Apr '20

On Thu, Mar 26, 2020 at 3:44 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Try it and see? I can't find any concrete documentation one way or the > other, although it seems BuildRequires generally follows what Requires > does. You may need to ask the people who maintain RPM. > > There are other issues in the spec file, however, like: > > --with-libfreeradius-ldap-include-dir=/usr/local/openldap/include \ > --with-libfreeradius-ldap-lib-dir=/usr/local/openldap/lib64 \ > > are specific to LTB, might want to do something like they did around line > 447 to only do this if the LTB openldap is in use. > Awesome! Thank you very much for the input! Will report how things go -Dave

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical