openldap-technical September 2017

openldap-technical@openldap.org

54 participants
164 discussions

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 8:18 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > On 09/18/2017 06:25 PM, Quanah Gibson-Mount wrote: >> Numerous projects have BSD-style licenses, this isn't OpenLDAP >> specific. So yes, you should already have a legal team, if that's >> necessary in your case, that's familiar with dealing with FOSS >> licenses, to review them. > > Not really. Not that many any more. But in fact I try to avoid using such > projects. Certainly I do not consider contributions into these. I think > that is not worth the effort. Unfortunately, I have to conclude that > OpenLDAP project seems to confirm my assumption. You generally seem fairly convinced the world is aligned against you. I'm not sure there's a solution to that that the OpenLDAP project can help you with. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Instructions for Open LDAP library?
by Martin van den Nieuwelaar 18 Sep '17

18 Sep '17

Hi People, I'm writing an application using Qt and wish to use the openldap library within my program to query an LDAP server. I have been searching for instructions on using the library from a client point of view but have not been successful. I tried using the man pages and I think I'm part way there but have reached an impasse on the correct way (or any way at all for that matter) to extract the results from an LDAPMessage *. I have an example search working using the command line program ldap_search, so the next thought is to look at the source for ldap_search and see what calls it makes to figure things out. This somehow seems like the wrong way to be going about things however. Is there something equivalent for openldap to the documentation for libcurl, https://ec.haxx.se/libcurl-easyhandle.html ? If there is that would be brilliant. I also tried searching for 3rd party howtos and tutorials and there are a few of those but invariably they use now deprecated library calls. Regards, -Martin -- R A Ward Ltd. | We take the privacy of our customers seriously. Christchurch | All sensitive E-Mail attachments MUST be encrypted. New Zealand

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 8:11 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > On 09/18/2017 06:27 PM, Quanah Gibson-Mount wrote: >> git is a pretty standard tool. Interestingly, numerous people seem to >> have no issue using git to check out the source, do a git format >> patch, and submit it for inclusion with the project. You can see this >> rather trivially by looking at my scratch repo where I've been >> consolidating contributed patches for review and inclusion in OpenLDAP: > > Yes, git is great tool and it is standard. No doubt about that. But why > there is no official OpenLDAP repo on github/gitlab? There is: <https://github.com/openldap/openldap> > Why the people > cannot contribute by simple pull requests? It is rather simple to set up > and maintain. And it lowers the entry barrier by a huge amount. Would be > ideal for fixes in man pages. Once you've gone to the work to do a change and commit it, there is little difference from that point of doing a pull request or a git format patch. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 18 Sep '17

18 Sep '17

Radovan Semancik wrote: > On 09/18/2017 06:25 PM, Quanah Gibson-Mount wrote: >> Numerous projects have BSD-style licenses, this isn't OpenLDAP specific. So >> yes, you should already have a legal team, if that's necessary in your case, >> that's familiar with dealing with FOSS licenses, to review them. > > Not really. Not that many any more. But in fact I try to avoid using such > projects. Certainly I do not consider contributions into these. I think that > is not worth the effort. Unfortunately, I have to conclude that OpenLDAP > project seems to confirm my assumption. The OpenLDAP license has been in use in its present form since 2003. It has certainly stood the test of time, which is something many other licenses cannot claim. Relicensing all of the code would be a non-trivial effort, as well. Basically everything you've posted amounts to "why doesn't this project that has been running for 19 years not conform to my newbie expectations?" It is not the community's obligation to conform to newcomers' expectations. It's the newcomer's obligation to observe existing community policies. That's true in all communities, not just open source. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 7:13 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > >> That's incorrect. It's a BSD-style license, it doesn't get much more >> basic than that. <https://en.wikipedia.org/wiki/BSD_licenses> > > The point is that is may be BSD-style license. But it is not a BSD > license. I may need to run OpenLDAP license with our company lawyer to > make sure it is BSD-like and to be sure about the implications that might > be hidden there. I would not need to do that with a BSD license. > Everybody knows that one already. That's the power of standardization. It > saves time and lowers barriers. Numerous projects have BSD-style licenses, this isn't OpenLDAP specific. So yes, you should already have a legal team, if that's necessary in your case, that's familiar with dealing with FOSS licenses, to review them. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 7:08 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > On 09/18/2017 05:20 PM, Howard Chu wrote: >> Radovan Semancik wrote: >>> I would ... if this was a wiki, or github-like pull request and if >>> there was an example of how a good result should look like. But it >>> does not make sense for me to spend few hours just figuring out how >>> to contribute documentation fix. >> >> So you're still saying, it's fine for other people to put in the hours >> to produce something you benefit from, but it's too much trouble for >> you to contribute in return. And in the meantime, it's perfectly OK >> for you to sit back and complain that things haven't been fixed. Got it. > > I'm afraid that you haven't got the point. According to my experience > people are willing to contribute. I'm willing to contribute. Just the > barrier is too high. But the worst thing is that I feel that the barrier > could be much lower if there was a bit of will to lower it. But the will > is just not there. And I do not see why. It is not 1990s any more. There > are ways how to make cooperation easier. Why not use them? git is a pretty standard tool. Interestingly, numerous people seem to have no issue using git to check out the source, do a git format patch, and submit it for inclusion with the project. You can see this rather trivially by looking at my scratch repo where I've been consolidating contributed patches for review and inclusion in OpenLDAP: <https://github.com/quanah/openldap-scratch> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 6:02 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > Again, it would be probably already contributed to the project if the > process was more user friendly. But what do I really need to do to > contribute? First, I have to decide whether I'm OK to contribute under > OpenLDAP license. The license is not really standard and I have to check > whether there are some obligations or limitations for my future work. That's incorrect. It's a BSD-style license, it doesn't get much more basic than that. <https://en.wikipedia.org/wiki/BSD_licenses> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 18 Sep '17

18 Sep '17

Radovan Semancik wrote: > Hi, > > The "cn=config" configuration method is clearly superior. However, there are > serious practical issues. Firstly, the documentation leaves a lot to be > desired. Until recently almost all examples shown the slapd.conf way, > cn=config equivalent was simply missing. Unless I have missed something most > manual pages still assume the slapd.conf configuration method. And so on. These perennial arguments keep coming up. If you want things to improve, contribute. Anyone can write a manpage. Hardly anyone ever does. Everyone sits back and moans while waiting for someone else to fix things for them. That's not what open source projects and communities are about. > Secondly, there are operations that simply cannot be done using ldpamodify in > cn=config (e.g. removal of a suffix database). And thirdly and most > importantly: it is a real pain to remember the configuration schema and write > a multi-line ldapmodify command-line even for simple operations. In most cases you don't need to write multi-line ldapmodify commands. That's what ordering prefixes are for. > Especially > given that you have to translate suffix names (dc=example,dc=com) to > configuration DNs (olcDatabase={1}mdb,cn=config), set up non-trivial > configuration (e.g. replication) and so on. The cn=config method may be > superior. But it is not user friendly. Not even close. > > But, OpenLDAP is an open source project. If there is something that a user > does not like then there is always something that can be done about it. For > example, I like cn=config, but I hate the lack of tooling. Therefore I have > created the missing tools: > > https://github.com/Evolveum/slapdconf Again, if you want the project to improve - contribute. 3rd party tooling dilutes the knowledge pool. If you think you've improved some aspect of the code, contribute it back to the 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/

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Thursday, September 14, 2017 3:06 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Hi, > > > I am trying to see what is the best and recommended way of > deploying/starting ldap, OLC or conf file based? i was in the impression > that conf file based is easy and more controllable approach than OLC? slapd.conf is deprecated, and support for it will be removed in a future release. It is recommended taht new deployments use cn=config. I would say "easy and more controllable" are not measurable, nor are they relevant. I find cn=config to be trivially easy, for example, and allows me to execute much better control over my deployments. YMMV. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

Unknown server id in contextCSN
by Tim 18 Sep '17

18 Sep '17

Heya, Currently running OpenLDAP 2.4.40 (most recent Centos patch) in a MirrorMaster environment. The two instances have olcServerIds of 101 and 102.. Within the syncprepl, each server is using a RID of 999. Everything appears to be working fine - but each of my providers now have replication cookies that seem to reference some other servers?? contextCSN: 20170918082017.961842Z#000000#*065*#000000 contextCSN: 20170915112957.845512Z#000000#*066*#000000 Is this an oddity/bug? Or could someone point me in the right direction to better understand what I'm seeing and where I've got confused? Thanks in advance. -- Tim tim(a)yetanother.net

2 2

← Newer
1
...
5
6
7
8
9
10
11
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2017