openldap-technical September 2017

openldap-technical@openldap.org

54 participants
164 discussions

Re: Instructions for Open LDAP library?
by Martin van den Nieuwelaar 20 Sep '17

20 Sep '17

On 19/09/17 08:00, John Lewis wrote: > On Mon, 2017-09-18 at 14:31 +1200, Martin van den Nieuwelaar wrote: >> 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. > The libcurl library supports LDAP. Howard Chu even wrote a new LDAP > implementation for it back in 2010 to make it fully asynchronous. Is > there a good reason not to use it? > Thanks for the suggestion. I hadn't even thought to see if libcurl could perform LDAP queries, but indeed it looks like it can so this is definitely worth looking into. In the interim I did get my Qt program working, not by using the openldap library calls for which I'm still none the wiser but by using Qt's very capable and well documented QProcess class for running external programs and calling the ldapsearch command line program. Thanks again for the reply. -- R A Ward Ltd. | We take the privacy of our customers seriously. Christchurch | All sensitive E-Mail attachments MUST be encrypted. New Zealand

1 0

Using overlay rwm to rewrite search base depending on search filter
by Clément OUDOT 20 Sep '17

20 Sep '17

Hello, I am playing with overlay rwm to try to change the base DN of a search depending on a value in search filter. The goal is to rewrite base "dc=example,dc=com" to "dc=test,dc=example,dc=com" if I have (uid=login@test) in the LDAP filter. Has someone already done this? My configuration for the moment is the following, but I don't understant how to capture a value in searchFilter context to use it in searchDN context: dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm olcRwmRewrite: rwm-rewriteEngine on olcRwmRewrite: rwm-rewriteContext searchFilter olcRwmRewrite: rwm-rewriteRule "uid=(.*(a))(.*)" "uid=$0$1" ":" olcRwmRewrite: rwm-rewriteContext searchDN olcRwmRewrite: rwm-rewriteRule "dc=example,dc=com" "dc=${searchFilter($1)},dc=example,dc=com" ":" Thanks for your help! Clément.

1 1

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Friday, September 15, 2017 8:48 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > So I've been putting off posting about this, but I recently upgraded to > 2.4.45, stopped using the memberof overlay, no longer have a node with > serverID 0, and overall think my ldap servers should be in good shape > :), and it's still happening, so I thought it was time... > > I'm getting weird errors in my logs about group replication changes: > > Sep 15 03:55:16 minerva slapd[71654]: null_callback : error code 0x14 > Sep 15 03:55:16 minerva slapd[71654]: syncrepl_message_to_op: rid=003 > be_modify uid=arc464,ou=group,dc=cpp,dc=edu (20) These aren't "wierd errors". 0x14=20. I.e., you're simply getting the same error logged twice. > As far as I can tell, all the updates succeed and the objects are > exactly the same on all the replicas, so these failures just seem to be > log noise? Well, error code 20 is "type or value already exists". If the replica and the masters are starting from the same point, this would tend to imply that the replica is receiving the change multiple times, and it's failing on the subsequent modify operations. There's not enough information here to really deduce much beyond that. I've seen this occur in MMR situations where two masters were updating the same entries within a short window of each other. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

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

19 Sep '17

--On Tuesday, September 19, 2017 7:31 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > What I meant were external contributions from people outside of the core > team. And I have obviously missed (at least) one such contribution. I'm > sorry for this. My fault. And I get your point and I apologize for this > confusion. One thing you're likely missing is that -devel is generally used for discussion of new feature requests. The ITS system (and thus the openldap-bugs list) are where discussion generally occurs for contributions related to existing features. So the -devel list is generally much lower traffic. For example, this is the archive for September (so far): <http://www.openldap.org/lists/openldap-bugs/201709/> > I just want to point out I haven't failed to notice that all of my other > points got ignored. I didn't think any of the rest of what you said was valid so there was nothing to address. You came in with a premise that was not based on fact. There are numerous people contributing that are not direct project team members, and they don't have issues with the contribution process. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

19 Sep '17

--On Tuesday, September 19, 2017 11:54 AM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > Regarding the pull requests and discussions: I have checked the devel > mailing list for several months and I haven't see any discussion > regarding a contribution. Really? You must not have looked very hard then. <http://www.openldap.org/lists/openldap-devel/201709/msg00000.html> covers some 22 contributions. <http://www.openldap.org/lists/openldap-devel/201709/msg00003.html> discussions some contributions related to man page fixes. <http://www.openldap.org/lists/openldap-devel/201706/msg00004.html> covers work I did to make TLS command line options for the ldap* tools <http://www.openldap.org/lists/openldap-devel/201706/msg00006.html> is part of an ongoing discussion of allowing ldap clients to use a specific local address <http://www.openldap.org/lists/openldap-devel/201706/msg00000.html> is a discussion about adding ldap_init_fd contribution from samba etc. > What I see as a major problem is that there is no will. OpenLDAP project > clearly needs major improvement. But there are almost no contributors to > improve the project. As demonstrated by the above you clearly are incorrect. I would generally suggest you withhold comment on the project until you have some clue what you're talking about. --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 19 Sep '17

19 Sep '17

--On Friday, September 15, 2017 12:49 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Personally I strongly prefer static configuration because it's so much > easier to control it with the usual idempotent config management > techniques (puppet, ansible, etc.) which you need for the rest of the > system anyway. Those are all systems designed to manage flat file configurations. cn=config is not a flat file configuration, so it makes sense they're fairly useless when confronted with a concept that's significantly more forward thinking. > I'd even state that it's a strong plus of OpenLDAP compared to other LDAP > server implementations to still provide this configuration method. I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime, along with other critical configuration bits, such as deploying new schema, additional overlays, etc. Being able to fully automate deployments w/o requiring restarts was an exceptional win for me. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 11

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

19 Sep '17

--On Monday, September 18, 2017 8:48 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: >> b) Since cn=config is simply a tree, you could have your cn=config in >> git, commit your changes there, and use a tool like ldapdiff to create >> changesets to apply programatically. > > So instead of writing a single file (in one FS transaction) after letting > slaptest check it I have to write several files (multiple FS operations), > diff that and then apply multiple LDAP operations. Hm? How is this any different really than tracking slapd.conf in git? And plenty of people break out slapd.conf into multiple files and use "include" handling to pull, such as with schema, ACLs, etc. I see no difference here. > Yeah, sounds really great regarding error handling. How does this differ from slapd.conf? You get no error handling with that, either, if you modify it and commit it to git. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Radovan Semancik 19 Sep '17

19 Sep '17

On 09/19/2017 08:56 AM, Ulrich Windl wrote: > Please don't mix git with github! While github makes some things > easier to do, it's not required to use gir (as you surely know). The > problem with using github is that everybody has to use github then > (will pull requests and related discussions be visible in the mailing > list?). That's obviously not a correct statement. It is not true that "everybody has to use github". The true statement would be "people may use github as an alternative contribution path". I do not propose to make a complete switch to github. What I propose is to make official github/gitlab mirror and use that as an alternative contribution path. Regarding the pull requests and discussions: I have checked the devel mailing list for several months and I haven't see any discussion regarding a contribution. So obviously, this method does not work well either. I'm using github for years and I contribute to several projects. And there are always some ways how to cope with github. Sometimes the github discussions are limited to the technicalities of the merge and all other discussion is referred to mailing list. In addition to that github has hooks that can be used to direct the comments directly to the mailing list. The best solution that I have seen is probably in the Apache CXF project where pull request comments are automatically synchronized with bug tracking system comments. There is always a way ... if there is a will. What I see as a major problem is that there is no will. OpenLDAP project clearly needs major improvement. But there are almost no contributors to improve the project. I'm trying to explain that there may reasons why people are not keen to contribute. But what I see as a response only makes all of this worse. I'm sorry about that. Really sorry. > You could still use "format-patch" to send your change requests via > E-Mail. You could still write your letter by hand, put it into envelope and send it by post. But we are usually not doing that these days, are we? I'm quite sure we all know the reasons. -- Radovan Semancik Software Architect evolveum.com

1 0

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

18 Sep '17

Michael Ströder wrote: > Quanah Gibson-Mount wrote: >> b) Since cn=config is simply a tree, you could have your cn=config in >> git, commit your changes there, and use a tool like ldapdiff to create >> changesets to apply programatically. > > So instead of writing a single file (in one FS transaction) after letting > slaptest check it I have to write several files (multiple FS operations), diff > that and then apply multiple LDAP operations. slapcat -b cn=config -> 1 LDIF file. > P.S.: The day slapd.conf option is dropped from slapd I should start writing > my own LDAP server. ;-) You better get started now, if you want it to be ready to use by then. -- -- 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 10:59 PM -0500 Andy Dorman <adorman(a)ironicdesign.com> wrote: Hi Andy, > FWIW, we also need the git trail of changes over time. I have not > figured out a good way to do that with OLC. Well, there are a few options I suppose: a) You could set up an accesslog database that stores the changes made to cn=config over time. If you had to have it in git, it shouldn't be particularly difficult to write a tool to parse those changes out into some format you desire b) Since cn=config is simply a tree, you could have your cn=config in git, commit your changes there, and use a tool like ldapdiff to create changesets to apply programatically. Then you keep a full git history of your configuration, and have the ability to create changesets out of it. It might actually be kind of useful to develop something like ldapdiff (or update it accordingly) that works specificaly with git commits. You could build an entire automation setup for pushing out changes from that. ;) > === To add the same attribute to our dev server running OLC: > > - print the current OLC config to copy exactly how the current object > class is stored for use in my changes.ldif file. I do this because the > first time I did an OLC change I had a typo and the server was down for > almost an hour while I tried to find the typo and recover. > > - prepare a change.ldif file using the old OLC config for the object > class along with the new attribute definition. Adding the same new > attribute as above looks like this: > > dn: cn={5}antespam,cn=schema,cn=config > changetype: modify > add: olcAttributeTypes > olcAttributeTypes: ( idInteger:29 NAME 'asEstReportCardSpan' DESC 'How > many days of data to include in EST Report Cards' SUP idInteger ) > - Looks correct. > delete: olcObjectClasses > olcObjectClasses: ( idDomain:1 NAME 'asDomain' DESC 'A domain using > AnteSpam' SUP top AUXILIARY MUST ( asSidelineServer $ asPlan ) MAY ( > asAcceptUnknown $ asActive $ asAdvanced $ asBlockList $ asCountAccepted $ > asCountDiscarded $ asCountRejected $ asCountSent $ asCountSidelined $ > asCountVirus $ asDestination $ asDisposeThreshold $ asPassList $ > asSidelineThreshold $ asSpam $ asVirus $ asCountValid $ > asCountUnconfirmed $ asCountInvalid $ asCountIndependent $ > asAddressListReminder $ asRejectInvalidSender $ asPingAddress $ > asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $ > asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asExternalAuth $ > asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $ asBackup $ > asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $ > asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $ > asOutboundAccount $ asOutboundNotify $ asBPReportEmail $ > fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) ) > - You can delete by index number. It'd be simpler to do something like delete: olcObjectClasses olcObjectClasses: {3} (Or whatever index number it is). This avoids having to write out the entire object for the delete operation. I've used that as well with ACLs, which is handy. Although if you have a useful ldapdiff tool, then it'll generate this correctly for you as well. > add: olcObjectClasses > olcObjectClasses: ( idDomain:1 NAME 'asDomain' DESC 'A domain using > AnteSpam' SUP top AUXILIARY MUST ( asSidelineServer $ asPlan ) MAY ( > asAcceptUnknown $ asActive $ asAdvanced $ asBlockList $ asCountAccepted $ > asCountDiscarded $ asCountRejected $ asCountSent $ asCountSidelined $ > asCountVirus $ asDestination $ asDisposeThreshold $ asPassList $ > asSidelineThreshold $ asSpam $ asVirus $ asCountValid $ > asCountUnconfirmed $ asCountInvalid $ asCountIndependent $ > asAddressListReminder $ asRejectInvalidSender $ asPingAddress $ > asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $ > asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asEstReportCardSpan $ > asExternalAuth $ asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $ > asBackup $ asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $ > asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $ > asOutboundAccount $ asOutboundNotify $ asBPReportEmail $ > fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) ) > > - After the changes.ldif is done, I just pass it to ldapmodify and, as > long as there are no typos, everything works beautifully. > > And lastly, I will admit I haven't researched it recently, but when OLC > first came out I did not find any docs on how to set OLC up in a > master-slave arrangement so the OLC changes on the master are replicated > to the slaves? At least I assume that is how changes should be handled? This is already covered in test059 in the OpenLDAP test suite. ;) For this scenario what you have is: provider server with: cn=config db (master configuration) back-ldif db (replica configuration) replica server(s) that use syncrepl with the suffixmassage parameter to replica from the back-ldif DB on the master. This allows you to isolate out the replica configuration, since it by definition has to differ from the provider configuration. To update the replica configs, you simply do a write to the ldap provider's back-ldif DB, and the replicas all pull it down immediately. One write op -> Updates all replicas. > So anyway, we need a git trail of changes (or some sort of change log) > and I need to figure out how to set up delta-syncrepl for cn=config and > then seamlessly and safely transition 15 slaves and a master. If I can > do this I will jump on the cn=config wagon. This is possible as noted above. ;) I've put it on my to-do list however to create a test script that covers delta-sync replication for cn=config (There's none currently covering that). Then it can be used as an example. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
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