OpenLDAP 2.5 plans and community engagement
by Ondřej Kuzník
Hi all,
as 2.4 has finally stabilised and the ITS list is getting shorter not longer
(thanks to Quanah's tireless efforts), the project can finally tackle some of
the long-standing pain points. So this post aims to outline where we are/want to
move to as well as to start a discussion and hopefully get you, the community,
more involved on the road to 2.5 and beyond.
We would love to welcome more people to participate in the project and make it
more active and resilient. People of various skills and experience can make a
difference, I am personally happy to assist anyone who wants to contribute with
getting up to speed and start helping out, and for sure I'm not the only one.
Also OpenLDAP is about more than just C programming and I'll try to outline the
main areas where we want to focus our work in the short term here:
One of the pain points in the 2.4 release cycle was the level of testing done on
the code before we have released. There are issues with the existing test suite
that make testing hard and I will come to how this could be tackled in a later
email. In the short term however, we could benefit from having the tests we have
run more often and on more diverse environments. If you have a chance to run it
regularly, in a loop and report issues picked up, that would be a definite help.
If you could help extend the test suite to cover scenarios that are of interest
to you and are not appropriately covered yet, even better.
Another issue frustrating both users and contributors to the project has been
the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its
usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via
Gitlab's built in Bugzilla integration) are being made and this should make the
issue tracker searchable again, help with triage as well as greatly improve the
visibility into our release process. Especially after the migration, this would
be another opportunity for anyone with just a bit of spare time to help by
triaging open issues so we can make timely releases of better quality.
I'm sure everyone agrees our website could do with a redesign. We've started
looking into this but it has been a slow process so far and if you can
contribute here, that might speed things up. It doesn't need much, keeping it a
collection of static html pages, just a slight reorganisation of the content
that is more friendly to anyone visiting it for the first time plus a simplistic
design along the lines of many other open source projects (openssl.org for
example) would go a long way.
This leads to documentation, much of which is already hosted on the website.
While I believe there is good work to be done on the admin guide, it is one of
the better parts of our documentation. This is where user feedback on its
usefulness is more important, please read it, have people on your team read it
and show it people just getting started and report which parts are confusing,
how they could be improved. We also intend to document our contributor
guidelines in a more readable way.
The FAQ site however is on the opposite side of the spectrum and will be removed
at some later point. There have been two suggestions how to replace it. We could
use Gitlab internal wiki or a static webpage site based on Gitlab pages and we
want to transfer over articles that are still relevant.
In general, moving to Gitlab should let us integrate CI much better, especially
if there are people willing to integrate and manage external runners. As
mentioned above, we could definitely do with more regular testing on non-Linux
platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be
automatically tested.
Let us know what the pain points have been with OpenLDAP when you were just
starting, right now and if you have a suggestion how to make it easier to start
using it. Or if you wanted to contribute, has anything discouraged you?
There are things we might not be able to influence easily (LDAP itself can be
complex), but a fresh look might help direct efforts in the right direction.
Thanks ever so much for reading this far. This email is long enough already so I
will follow up with another one about my long term plans to overhaul the test
infrastructure and other tools that might be worth introducing to help with
setting up and managing OpenLDAP deployments.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
4 years, 1 month
Re: Openldap Acl
by Quanah Gibson-Mount
--On Sunday, July 28, 2019 11:47 PM +0100 Meryem Fahim
<meryem.f97(a)gmail.com> wrote:
Hello,
Please keep replies on the list.
> Hello
> Thank you for taking the time to respond.You have asked me to provide you
> with my set of ACLs so here it is:
> dn: olcDAtabase={0}config,cn=config
You're changing the ACLs on the wrong database. That DN is clearly for the
cn=config datbase, and so would not apply to the DB that contains your
users, etc.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 1 month
Openldap Access Control
by Meryem Fahim
HELLO;
i'm working on an Openldap project where im supposed to create groups and
users and be able to work with phpldapadmin,I've done all of that.
Now I want to modify access whereas ensaUser and estUser when logging in
will be able to see only the branch they are in(and give that privilege to
admin only)
I tried so many ACLs (using ldapmodify) but nothing seems to work,when I
log in with one of the users I still can see the whole dataBase,I would
appreciate some help.thank you
4 years, 1 month
slapd-sock v2.4.47 not returning LDIF
by Giuseppe De Marco
Hello everyone,
I made a configuration to get slapd-sock to work with a python3 server
(gevent).
The slapd configuration can be reproduced less then a minute using this
ansible playbook:
https://github.com/peppelinux/ansible-slapd-eduperson2016
the python3 server is available at the following resource, slapd-sock
backend configuration can be found in the README file:
https://github.com/peppelinux/pyMultiLDAP
It is the following:
ldapadd -Y EXTERNAL -H ldapi:/// <<EOF
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModuleLoad: back_sock.la
EOF
ldapadd -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={4}sock,cn=config
objectClass: olcDbSocketConfig
olcDatabase: {4}sock
olcDbSocketPath: /var/run/multildap.sock
olcSuffix: dc=proxy,dc=unical,dc=it
olcDbSocketExtensions: binddn peername ssf
EOF
I tested that this configuration doesn't have any problems in a Debian 9
installation (slapd 2.4.44) but in a Debian10 (2.4.47) does. Even if I use
"servers/slapd/back-sock/searchexample.pl" [1] I get the same faulty
result, described as follow:
````
# extended LDIF
#
# LDAPv3
# base <dc=proxy,dc=unical,dc=it> with scope subtree
# filter: uid=mario
# requesting: ALL
#
# search result
search: 2
result: 0 Success
text: OK
````
As we can see RESULT was found but with any preceeding ldif.
Looking into /var/log/slapd.log I found the same behaviour of Debian9
installation:
````
[25-07-2019 10:33:57] slapd debug conn=1036 fd=20 ACCEPT from IP=
127.0.0.1:54674 (IP=0.0.0.0:389)
[25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND
dn="cn=admin,dc=testunical,dc=it" method=128
[25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND
dn="cn=admin,dc=testunical,dc=it" mech=SIMPLE ssf=0
[25-07-2019 10:33:57] slapd debug conn=1036 op=0 RESULT tag=97 err=0 text=
[25-07-2019 10:33:57] slapd debug conn=1036 op=1 SRCH
base="dc=proxy,dc=unical,dc=it" scope=2 deref=0 filter="(objectClass=*)"
[25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH
base="ou=people,dc=testunical,dc=it" scope=2 deref=3
filter="(objectClass=*)"
[25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH
attr=eduPersonPrincipalName schacHomeOrganization mail uid givenName sn
eduPersonScopedAffiliation schacPersonalUniqueId schacPersonalUniqueCode
userPassword
[25-07-2019 10:33:57] slapd debug conn=1034 op=5 SEARCH RESULT tag=101
err=0 nentries=4 text=
[25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0)
[25-07-2019 10:33:57] slapd debug conn=1036 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text= OK
[25-07-2019 10:33:57] slapd debug conn=1036 op=2 UNBIND
[25-07-2019 10:33:57] slapd debug conn=1036 fd=20 closed
````
I also tried to use admin credentials, as shown in the slapd log.
I also tried to do a fresh slapd installation by hands, on Debian9
slapd-sock works (searchexample.pl
<https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/...>
and pyMultiLdap) but not Debian10.
I read that there are two additional features regarding slapd-sock in
openldap 2.4.47. These are:
- Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051)
- Added slapd-sock ability to send extended operations to external
listeners (ITS#8714)
My doubts:
Is there any need to change configuration, following ITS#8714 and ITS#8051,
to get it to work in Debian10 ?
or
Am I facing a bug present in openldap 2.4.47 ?
Thank you in advance for everything you would tell me,
Cheers
[1]
https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/...
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco(a)unical.it
4 years, 1 month
Mapping gid numbers
by JC
My question is not strictly an LDAP one, but perhaps somebody here with experience in the LDAP and Linux worlds can throw some light on it.
I understand how to map attributes, as defined in an LDAP server, to other attributes in a Linux when the NSS framework is used in the latter. Is it possible to map values of attributes? Let's say I have an OpenLDAP server that defines a certain group with a gid number 10000. Would it be possible to map that 10000 to (say) 5000 in the Linux system? That is, every time an operation is executed in the Linux system that uses the group information, the gid would be retrieved from the OpenLDAP server as 10000, and automatically be converted to 5000. Can this be done?
4 years, 1 month
Re: where is debuglevel documented ?
by danielle lampert
Hello,
yes I was asking for the log levels of the command-line tools like
ldapsearch. Thanks for your answers.
This doc helps ( https://www.openldap.org/doc/admin24/runningslapd.html )
but is not completely right, as levels 4 and 8 don't do anything special.
I will rely on the this doc for my tests, thanks again.
D.L.
Le lun. 22 juil. 2019 à 16:14, Quanah Gibson-Mount <quanah(a)symas.com> a
écrit :
> --On Monday, July 22, 2019 10:56 AM -0400 Brian Reichert
> <reichert(a)numachi.com> wrote:
>
> > I think that the OpenLDAP server and client share debug flags. I may be
> > wrong on this.
> >
> > https://www.openldap.org/doc/admin24/runningslapd.html
>
> This is correct. It's trivial to grep the source and confirm this as well.
>
> --Quanah
>
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
>
4 years, 2 months
Re: Intensive disk write after long-running LDAP activity terminated
by Tamás Rébeli-Szabó
Quanah,
thank you for your warning.
We are aware that it is a very old release and a version upgrade is already
being planned.
But for the moment, that is the currently installed version and that is
what produced the strange phenomenon.
Regards,
tamas
Quanah Gibson-Mount <quanah(a)symas.com> ezt írta (időpont: 2019. júl. 22.,
H, 15:25):
> --On Monday, July 22, 2019 2:20 PM +0200 Tamás Rébeli-Szabó
> <tamas.rebeli.szabo(a)webvalto.hu> wrote:
>
> >
> >
> >
> > Hello,
> >
> > we had a long-running (several days) process doing add and modify
> > operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3.
>
> I would note you're talking about OpenLDAP and LMDB releases that are over
> 4 years old, past which point numerous issues have been fixed for both.
>
> LMDB 0.9.15 Release (2015/06/19)
> OpenLDAP 2.4.41 Release (2015/06/21)
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
4 years, 2 months
Openldap issues user issues after updating user groups
by 王峰
Hello, wish you happiness!
Sorry, take up your precious time. I encountered a problem. In the openldap HA environment, the update user group found that it was not synchronized to the client in time (8 hosts, 5 stations, 3 syncs, not synchronized, waiting for half an hour to complete synchronization). Has anyone encountered such a problem? And would like to know how to
troubleshoot such problems, I use openldap soon. thank you very much!
发送自 Windows 10 版邮件应用
4 years, 2 months
Intensive disk write after long-running LDAP activity terminated
by Tamás Rébeli-Szabó
Hello,
we had a long-running (several days) process doing add and modify
operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3.
When the process was stopped, we experienced minutes of intensive disk
write by LMDB.
The LMDB option dbnosync is not set.
Checking git we see that there should be a transaction commit in LMDB after
every LDAP add/modify operation, and the updating of on-disk contents
should happen after each LDAP add/modify operation.
Furthermore, at the OS level, dirty pages should be generally flushed every
5 seconds.
So we wonder what could possibly cause such a significant I/O burst?
Regards,
tamas
4 years, 2 months
