iNetOrgPerson doesn't exist?
by Luca Stancapiano
Hi all, I'm triing to create a user with openldap 2.4
dn: uid=rrrrrr,ou=users,dc=my-domain,dc=com
objectClass: iNetOrgPerson
uid: iiiiii
but it doesn't seem recognize the objectClass producing this error:
adding new entry "uid=rrrrrr,ou=users,dc=my-domain,dc=com"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax
Using other object classes is ok. What's the problem?
1 week, 4 days
dynlist vs memberof performance issues
by Mark Cairney
Hi,
I've been out the LDAP loop for a bit but the recent discussion of the
memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
removed the memberof elements from the database and replaced the
memberof overlay with dynlist the queries appear to work as expected but
are both a) slow and b) heavily CPU-intensive on the LDAP server.
2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738
(IP=129.215.17.9:636)
2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256
tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms
2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014
etime=0.000214 nentries=1 text=
2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 BIND dn="" method=163
2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030
etime=0.009084 text=SASL(0): successful result:
2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 BIND dn="" method=163
2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031
etime=0.000181 text=SASL(0): successful result:
2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND dn="" method=163
2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK"
authzid="mcairney(a)EASE.ED.AC.UK"
2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND
dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk"
mech=GSSAPI bind_ssf=256 ssf=256
2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024
etime=0.000409 text=
2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH
base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0
filter="(uid=mcairney)"
2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH attr=* +
2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=5 UNBIND
2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031
etime=13.233679 nentries=1 text=
2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 closed
I'm guessing that as the values are computed that this will be heavier
on the CPU but it seems a bit excessive? Has anyone else noticed any
similar performance issues?
This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I
guess this could be a factor but there's no io waiting on the server and
no swapping?
The database is on a par in size with our Production service ( about
400K user objects with 1 group object per user and then about 80K actual
groups of users)
The config for the primary DB (ACLs and rootPW redacted) is:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /opt/openldap/var/openldap-data/authorise
olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 2
olcReadOnly: FALSE
olcSecurity: ssf=1
olcSecurity: update_ssf=112
olcSecurity: simple_bind=64
olcSizeLimit: unlimited
olcSyncUseSubentry: FALSE
olcTimeLimit: unlimited
olcMonitoring: TRUE
olcDbEnvFlags: writemap
olcDbEnvFlags: nometasync
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: eduniType eq
olcDbIndex: gecos pres,eq,sub
olcDbIndex: eduniCategory eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: eduniSchoolCode eq
olcDbIndex: eduniIDStatus eq
olcDbIndex: eduniCollegeCode eq
olcDbIndex: eduniOrgCode eq
olcDbIndex: memberOf pres,eq
olcDbIndex: eduniLibraryBarcode pres,eq
olcDbIndex: eduniOrganisation pres,eq,sub
olcDbIndex: eduniServiceCode pres,eq
olcDbIndex: krbName pres,eq
olcDbIndex: eduPersonAffiliation pres,eq
olcDbIndex: eduPersonEntitlement pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: eduniIdmsId pres,eq
olcDbIndex: member pres,eq
olcDbIndex: memberUid pres,eq
olcDbIndex: eduniRefNo pres,eq
olcDbIndex: eduniTitle pres,eq
olcDbIndex: title pres,eq,sub
olcDbIndex: eduniCardNumber pres,eq
olcDbIndex: eduniYearOfStudy eq
olcDbIndex: description pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: aliasedObjectName eq
olcDbIndex: yubiKeyId pres,eq
olcDbIndex: isMemberOf pres,eq
olcDbIndex: hasMember pres,eq
olcDbIndex: proxyAddresses pres,eq,sub
olcDbMaxReaders: 96
olcDbMaxSize: 32212254720
olcDbMode: 0600
olcDbSearchStack: 16
structuralObjectClass: olcMdbConfig
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 02+00:00 00+04:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: olcDynListConfig
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
*******************************/
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
4 months, 2 weeks
LMDB, virtual machines, and copying mdb files
by selama＠gmail.com
I am working on developing a new document-oriented (XML+JSON) database, using LMDB as an engine, and I have two questions.
1. So far, it have been working really smoothly for me. But my one customer so far for the DB is really concerned about running LMDB in a virtual environment such as Docker, when performing reads and writes. Especially when mounting volumes. Their concern is because of the following caveat:
"Do not use LMDB databases on remote filesystems, even between processes on the same host. This breaks flock() on some OSes, possibly memory map sync, and certainly sync between programs on different hosts"
I think it shouldn't be an issue with Docker, but I want to be certain.
2. We have one server that updates the database, and another server with a read-only copy of the same database. Our plan was to simply copy the mdb files from the update machine to the read only machine, but we noticed that if we copy the file immediately after writing, the copy may end up being corrupted. My solution was to suspend all writing and wait few minutes before writing, to make sure everything back from memory, and I'm also using the "sync" command (not sure if it does anything here). It seem to be working, but I wonder if there is a more robust way of doing that? And also, is it safe to overwrite to the read-only server while it performs read transactions to the current file (or maybe rename it and copy to a new file with the same name)?
7 months
Fwd: [OldapWS] -> Proposal of a REST Web Service for CRUD Operations
by Howard Chu
Forwarding for exposure - any interest?
-------- Forwarded Message --------
Subject: [OldapWS] -> Proposal of a REST Web Service for CRUD Operations
Date: Fri, 16 Sep 2022 13:21:10 +0200
From: Olivier CHATOR <olivier.chator15(a)gmail.com>
To: openldap-devel(a)openldap.org
Dear all,
I am a "long time user" of OpenLDAP core parts.
If the core is very stable, I often received some request from application developers, complaining about the lack of REST Web Service API to manipulate their
Directory objects.
Of course, as far as I could see, there is commercial solution available to do this, or even a project using Spring.
But I could not see a simple proposal based on a simple Apache Server and "fully free" of rights.
I also saw (https://www.openldap.org/devel/contributing.html) that "The OpenLDAP Project welcomes contributions of independently-developed stand-alone
LDAP-related software packages suitable for distribution separately from existing packages (e.g., OpenLDAP Software, JLDAP, JDBC-LDAP)".
Then, I would like to propose a full Open Source first realease of a CRUD REST Web Service to manipulate OpenLDAP's Directory Objects.
I know that this first release is very limited in term of features, but I think it does the "core job", and may be a common base to be enriched to build a real
OpenLDAP REST API ?
Package available here: https://drive.google.com/drive/folders/1s4zlTleJ1JWhQWP2kLGHtTRofpWNevS7?...
Thanks for your time reading this proposal, do not hesitate to ask if you have any question.
Kind regards,
Olivier Chator
7 months, 1 week
LMDB key marshalling functions
by Søren Holm
Hi
I am working on utilizing LMDB in a project of mine. However I am
struggling a bit on how to manage marshalling of keys.
- packing of C structure into array
- and unpacking
- handling parrtial keys for range traversals.
Som months ago I read an article named "Shine and poverty key value
database LMDB in applications for iOS". It contained some clever
techniques. However the article is not longer to be found.
I feel like if I do the handling in a wrong way it will be a nightmare.
How to you handling your keys?
/Søren Holm
8 months
slapo constraint - uri constraint on object DN
by Benjamin Renard
Hello,
I try to affect an uri constraint on an attribute that storing the DN of
another object but I don't know what I have to put on the attribute
field of the URI. Have any of you already implemented such a constraint?
Constraint example for a attribute that storing another attribute value:
olcConstraintAttribute: title uri
ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
Thank you in advance,
--
Benjamin Renard - Easter-eggs
44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité
Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com
8 months
how to add index in replication scenario
by Uwe Sauter
Dear list,
I need to add an index for a new attribute in an active-active replication scenario.
I know I need to run slapindex to create the index for existing entries after I changed the
configuration file (yes, still on 2.4 with slapd.conf). But what is the correct procedure to update
both servers?
I'm a bit worried that the setup will become out-of-sync if I just update one server at a time.
Would it be better to stop the service on both servers and re-index the databases at the same time
before going online again?
Regards,
Uwe
8 months, 1 week
Re: Antw: [EXT] Re: LMDB 1.0 data.mdb format stability
by Howard Chu
Ulrich Windl wrote:
>>>> Howard Chu <hyc(a)symas.com> schrieb am 08.09.2022 um 01:34 in Nachricht
> <4bc80e7e-17f9-b385-6b11-2aab806edc43(a)symas.com>:
>> Steffen Michels wrote:
>>> Hi,
>>>
>>> We are considering using the mdb.master3 branch of LMDB, but it is not clear
>> to me whether the data.mdb format will remain stable. Is there a chance that
>>> another migration of all databases will be required in the future when
>> switching now?
>>
>> Yes. It is still unreleased because additional changes to the freelist
>> format are planned,
>> and possibly a few other changes.
>>
>> In any case, mdb_dump/mdb_load will always work for migrating to a new
>> version.
>
> I think at some point an inplace upgrade would be the way to go.
> On Linux filesystems, you could even upgrade yout ext3 to btrfs ;-)
That will never happen here. Supporting an in-place upgrade requires the library to support
old and new formats simultaneously, which is a waste of RAM. Anything that pushes the object
code size of the hot path over 64KB is a non-starter.
>
> Regards,
> Ulrich
>
>>
>>>
>>> regards,
>>>
>>> Steffen
>>
>>
>> --
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 months, 3 weeks
LMDB 1.0 data.mdb format stability
by Steffen Michels
Hi,
We are considering using the mdb.master3 branch of LMDB, but it is not
clear to me whether the data.mdb format will remain stable. Is there a
chance that another migration of all databases will be required in the
future when switching now?
regards,
Steffen
8 months, 3 weeks
