Re: Pending EPIPE fix for macOS
by Lorenz Bauer
Hello Quanah,
I have access to a macOS system, is there a test suite I can run which
would help?
Best
Lorenz
On 24 January 2018 at 17:39, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
> Hi Lorenz,
>
> The issue hasn't been lost, but we don't have easy access to an OSX system
> to test against. We'll see what we can get set up.
>
> --Quanah
>
>
> --On Tuesday, January 23, 2018 2:17 PM +0000 Lorenz Bauer <
> lmb(a)cloudflare.com> wrote:
>
>
>>
>>
>>
>>
>> Hello Howard, List,
>>
>> My bug and corresponding patch seems to have fallen through the cracks:
>> http://www.openldap.org/its/index.cgi?findid=8590
>>
>> Could you have a look and let me know whether you'd like any
>> modifications?
>>
>> Best
>> Lorenz
>>
>>
>>
>>
>>
>>
>> --
>>
>> Lorenz Bauer | Systems Engineer
>> 25 Lavington St., London SE1 0NZ
>>
>> www.cloudflare.com
>>
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
5 years, 10 months
Using virtual IP and N-way mutlimaster mode
by Clément OUDOT
Hello,
I would like to use the N-way mutlimaster mode and a virtual IP to
manage failover for applications. The virtual IP will be configured
trough keepalived.
To work with N-way mutlimaster, we must start OpenLDAP process on the
LDAP URI defined in cn=config olcServerID parameter. So we can't use
ldap://* to start the service. On the machine running the virtual IP,
I can of course listen on this IP by adding an LDAP URI in the start
command:
slapd -h ldap://master1.example.com ldap://virtual.example.com
But this command will not work it the virtual IP is not set on the
node as OpenLDAP refuses to start on an unknown IP.
Does anyone already face this issue and found a solution?
Clément.
5 years, 10 months
publisher migration or upgrade
by Scott Bickford
I have a RHEL 6 OpenLDAP 2.4.40 publisher with three subscribers in
production of the same version. In development i also have a RHEL 6
OpenLDAP 2.4.40 and one subscriber of the same version.
I got a RHEL 7 OpenLDAP 2.4.44 subscriber replicating in development.
I was able to load via slapadd the subscriber in about 30 minutes from an
overnight slapcat ldif.files from the publisher.
How can I upgrade the publisher without too much down time and ultimately
do the same in production? I want to also keep the same host names.
5 years, 10 months
Re: uidNumber for Service Accounts?
by Douglas Duckworth
Hi Michael
I added it using ldapadd.
I removed the account ObjectClass and now only use applicationProcess:
# preset, Service Accounts, blah
dn: uid=preset,ou=Service Accounts,dc=blah
objectClass: top
objectClass: extensibleObject
objectClass: applicationProcess
uid: preset
cn: preset
sn: preset
givenName: preset
title: Password Reset Account
description: Service Account For Resetting Passwords
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-6305
F: 212-746-8690
On Mon, Jan 8, 2018 at 4:49 PM, Michael Ströder <michael(a)stroeder.com>
wrote:
> Douglas Duckworth wrote:
> > adding new entry "uid=preset,ou=Service Accounts,dc=blah
> > ldap_add: Object class violation (65)
> > additional info: invalid structural object class chain
> > (account/applicationProcess)
>
> A directory entry must have a *single* structural object class. While
> there are usually multiple structural object classes listed only one of
> them is *the* structural object class. The others are parent object
> classes of the structural object class.
>
> Since 'account' and 'applicationProcess' both directly SUP abstract
> object class 'top' they count as two distinct structural object classes.
>
> > Though this does work as it's now in the LDAP server:
> >
> > dn: uid=preset,ou=Service Accounts,dc=blah
> > objectClass: top
> > objectClass: account
> > objectClass: applicationProcess
> > objectClass: simpleSecurityObject
>
> It's invalid and you might run into issues modifying this entry later.
> You should choose either 'account' or 'applicationProcess'.
>
> BTW: It should normally not be possible to add such entry.
> How did you add it? With slapadd or by using Relax Rules Control?
>
> Ciao, Michael.
>
>
5 years, 10 months
[Q] how to add country attribute to organizationalUnit objectclass?
by Zeus Panchenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
I'm using organizationalUnit to hold organization related data
and I'm wondering, how can I add country attribute to the object?
I find it stumbling, all other address attributes are available but country ...
I'd like to be able to do something like this:
- ---[ fake object quotation start ]-------------------------------------------
dn: ou=starfleet,ou=Organizations,dc=umidb
associatedDomain: starfleet.startrek.in
businessCategory: deep-space exploratory
businessCategory: peacekeeping
businessCategory: military service
l: Fort Baker
c: us
objectClass: country
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
ou: starfleet
physicalDeliveryOfficeName: Starfleet LLC
postalAddress: here the address to be added
postalCode: 12345
postOfficeBox: 1a
registeredAddress: here the address to be added too
st: California
street: Space St.
telephoneNumber: 922
- ---[ fake object quotation end ]-------------------------------------------
- --
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAlphvyQACgkQr3jpPg/3oyr49QCfW+SAQZeq9orhQasTuqtb2A2E
KZAAoLnO8DlP7z6bkNDe2JUKw9+JbnlI
=9epg
-----END PGP SIGNATURE-----
5 years, 10 months
Slapd pegs CPU every ten minutes
by Singley, Norman
Hi folks -
I have an issue with oldap 2.36 in which every ten minutes, slapd starts consuming all available CPU resources briefly. When this happens ldap searches timeout.
I have bumped up the cache size to 1.5 GB dn2id.bdb and id2entry.bdb are approx. 60 mb combined.
I'm reading through this:
https://www.openldap.org/devel/admin/tuning.html
I get errors (mismatched version) when I run DB_STAT (database environment version mismatch)
So, I don't have much more to report there.
I set logging back to the default to minimize logging.
There are three nodes in our cluster - one master.
Is there anything else I can look at to help troubleshoot? I am wondering what would cause slapd to peg the cpu at exactly 10 minute intervals.
Thanks for any help.
Norman Singley
Directory Services
406 243 6799
Norman.singley(a)mso.umt.edu
5 years, 10 months
Re: Antw: RE: [EXTERNAL] Incosistent config after schema modification
by Quanah Gibson-Mount
--On Monday, January 15, 2018 8:21 AM +0100 Ulrich Windl
<Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
>
>
>>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 11.01.2018 um 16:56
>>>> in
> Nachricht <5066F03FF8233B456CA521B7(a)[192.168.1.30]>:
>> --On Thursday, January 11, 2018 8:40 AM +0100 Ulrich Windl
>> <Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
>>
>>> But those weights are non-standard LDIF, right?
>>
>> OpenLDAP is the only directory server to implement
>> draft-chu-ldap-xordered-00 so far as I know. However, there is no
>> standard on how server configurations are managed, so it's rather
>> immaterial.
>
> But the mechanism is independent from server management (talking about
> LDIF), isn't it?
Hi Ulrich,
I'm not clear what you mean by "the mechanism". As far as I know, only
OpenLDAP implements having weighted attributes, and as far as I know, only
the OpenLDAP server has the concept of removing items in cn=config by
weight, or of doing inserts using the weight, etc, which is something
specific to the cn=config implementation in OpenLDAP.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 10 months
Re: mdb fragmentation
by Quanah Gibson-Mount
--On Thursday, August 24, 2017 8:30 PM -0500 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> Hi Geert,
>
> If I could, I would delete 8664 from the ITS system entirely as it was
> filed based on invalid information that was provided to me. It generally
> should be ignored.
>
> When a write operation is performed with LMDB, the freelist is scanned
> for available space to reuse if possible. The larger the size of the
> freelist, the longer amount of time it will take for the operation to
> complete successfully. When the database has gotten to a certain point
> of fragmentation (This differs based on any individual use case), it will
> be start taking a noticeable amount of time for those write operations to
> complete and the server processing the write operation does essentially
> come to a halt during this process. Once the write operation completes,
> things go back to normal. The only solution is to dump and reload the
> database (slapcat/slapadd or mdb_copy -c). Eventually, you will get back
> into the same situation and have to do this again.
>
> A recent option was added to the slapd-mdb configuration (rtxnsize) that
> can also help reduce the rate of fragmentation. There are some
> performance related issues you can find discussed on the -devel list from
> when it was added. Whether or not you are affected by them and whether
> or not the setting will help you in particular depends on whether or not
> your searches result in a large number of entries being returned. You
> can find some guidelines around tuning the parameter that I came up with
> in that thread. If you do not have an unlimited Zimbra License, the
> license check performed by the store servers will definitely affect this,
> since the result set is all active accounts which can be quite large.
>
> Additionally, I had at one point had a patch for the Zimbra build of
> OpenLDAP that made it very aggressive in finding freespace to reuse. I
> don't recall if it is still applied (I don't believe it currently is
> based on what I saw in github). It basically meant that in Zimbra, it
> would work extra hard to find reusable freespace, which would reduce the
> rate at which the database would fragment, but it also meant that once
> the DB was fragmented enough, it would amplify the amount of time it took
> for a write op to complete. I.e., it was a tradeoff of a longer time to
> reach a catastrophic state, but the state was more catastrophic once
> achieved.
>
> This is one area where LMDB differs significantly from back-hdb/bdb. You
> could have back-bdb/hdb databases that endured a high rate of write
> operations be in effect for years w/o needing maintenance. With LMDB,
> you get better read & write rates, but it requires periodic reloads.
I wanted to follow up on this, based on doing an examination of Geert's
database, and other affected databases. Geert already has this answer, but
it's useful for the general OpenLDAP community.
This fragmentation problem is not common. It depends entirely on size of
the entries in the database. The issue arises when entries in the LDAP DB
are greater than the LMDB pagesize (Usually 4KB) and then have frequent
updates. This most often occurs in one of two ways:
a) multi-valued attributes with a large number of values
b) a very large single-valued attribute (I.e., binary data)
For the first problem (a), there is code in the 2.5 release to address this
problem, called multival. This feature puts multi-valued attributes with a
(configurable) number of values into its own sub-database. For (b),
there's not really a solutionn, but it's pretty rare.
So for those who have entries that are < 4 KB, they will never see this
problem. Note that this is the size of the binary entry on disk, not the
size of the entry when exported to LDIF. The binary size is generally
significantly smaller than the LDIF version.
--Quanah
5 years, 10 months
Replication Broke
by Daniel Howard
Hello,
He have OpenLDAP replication set up based on the docs at
https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-ser...
I noticed recently a symptom, whereby a new user exists only on the primary.
So, I started to debug:
Master: (ldap0)
0-16:23 djh@ldap0 ~$ ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b
dc=qxxxxxxxxd,dc=com contextCSN
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20180113002606.399160Z#000000#000#000000
Consumer: (ldap1)
0-16:23 djh@ldap1 ~$ ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b
dc=qxxxxxxxxd,dc=com contextCSN
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20171121212631.416502Z#000000#000#000000
Ooohhh, my!
I have a lot of messages like this on the consumer:
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 DN:
uid=djh,ou=People,dc=qxxxxxxxxd,dc=com, UUID:
29f7fc06-7c2a-1035-83e5-9d6082b37970
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 inserted UUID
29f7fc06-7c2a-1035-83e5-9d6082b37970
Jan 12 16:28:55 ldap1 slapd[5383]: dn_callback : entries have identical CSN
uid=djh,ou=People,dc=qxxxxxxxxd,dc=com
20180113002133.183992Z#000000#000#000000
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 be_search (0)
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317
uid=djh,ou=People,dc=qxxxxxxxxd,dc=com
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 entry unchanged,
ignored (uid=djh,ou=People,dc=qxxxxxxxxd,dc=com)
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 DN:
uid=john,ou=People,dc=qxxxxxxxxd,dc=com, UUID:
ddaae880-7c2f-1035-83ed-9d6082b37970
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 mods
check (pwdChangedTime: attribute type undefined)
Jan 12 16:28:55 ldap1 slapd[5383]: do_syncrepl: rid=317 rc 17 retrying
What is funny is I can, for example, change the loginshell on my account,
and that replicates.
Is the latter message about pwdChangedTime a clue that maybe I had a schema
change on Master that hasn't been applied to Consumer?
Please advise on where to look next? Thanks!
-danny
--
http://dannyman.toldme.com
5 years, 10 months
proxyauth app against consumer with chainoverlay
by Michael Wandel
Hallo,
we are testing some application that use proxyauth against an consumer
with chain overlay with proxyauth. The oenldap version is 2.4.44 .
I'm not sure, if i made a mistake or is it a general problem to work
with proxyauth in a ldapmodify against a consumer with chain overlay
with proxyauth configured ?
It looks like, the provider doesn't see the proxyauth from the app request.
If someone has a hint or using this construct, I would be grateful for a
solution.
best regards
Michael Wandel
5 years, 10 months
