Re: OpenLDAP syncrepl woes
by Jeffrey Crawford
On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford
> <jeffreyc(a)ucsc.edu> wrote:
>
>> read that already:
>>
>> my original question was the following:
>>
>> Granted the above issues might be explained away in that we don't yet
>> have enough ram on the machines yet, however it does seem to present
>> us with a problem when we notice the discrepancy, how do we during run
>> time re-sync the data from the provider server? I have tried the slapd
>> -c rid=2,csn=20111114000000.000000Z but that doesn't seem to do any
>> good. (I've tried several different values of csn=0
>> csn=20111114000000.000000Z#000000#000#000000 etc. to no avail)
>
>
> Regardless of RAM limitations, you should never have an inconsistent
> database. However, so far, the only replication mechanism I've seen
> guarantee this is delta-syncrepl. This may be better in the upcoming
> OpenLDAP 2.4.27 for syncrepl.
>
> If you read the slapd man page for the -c option, it is quite clear:
>
> Use only the rid part to force a full reload.
Humm that didn't seem to work. I'm rebuilding so I'll give that another try.
>
>
>> from man slapadd
>>
>> LIMITATIONS
>> Your slapd(8) should not be running when you do this to ensure
>> consis- tency of the database.
>>
>> So how can I have slapd run, respond to what data it has currently yet
>> understand that it will update all it's data with the source provider
>> updating, adding, removing entries as necessary without removing the
>> database first?
>
> I don't understand why you would want slapd to respond with completely bogus
> data to any clients doing queries. If you're going to force reload the
> replica anyway, it makes much more sense to use slapadd from the master
> rather than trying to do it via syncrepl, which can take numerous amounts of
> time longer than doing it via slapadd, and during that entire time period,
> you have the possibility of sending out significantly erroneous data.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
9 years, 4 months
Possible ACL Issue while try to read Root DSE
by Axel Birndt
Hi @All,
i'am new on this list and i have a question.
While i'am using the tool web2ldap from Michael Stroeder and try to
create a new entry with this tool.
I'am using openldap with cn=config backend on ubuntu 10.04
Michael mentioned it could be a acl problem, because his tool couldn't
read the Root DSE
If i specify the search base and the adminuser i could see the content
of the Tree root.
ldapsearch -b "dc=2axels-company,dc=de" -s base 'objectclass=*' -h
localhost -D cn=admin,dc=2axels-company,dc=de -W
-------------------->>
abirndt@ubuntunb:~$ ldapsearch -b "dc=2axels-company,dc=de" -s base
'objectclass=*' -h localhost -D cn=admin,dc=2axels-company,dc=de -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=2axels-company,dc=de> with scope baseObject
# filter: objectclass=*
# requesting: ALL
#
# 2axels-company.de
dn: dc=2axels-company,dc=de
objectClass: dcObject
objectClass: organization
o: 2axels-company.de
dc: 2axels-company
description: Tree root
<<<<----------------------------------------
But if i use ldapsearch with the following command i got nothing:
ldapsearch -b "" -s base 'objectclass=*'
ldap_sasl_interactive_bind_s: No such object (32)
Could you help me please to identify if there is a problem with reading
the Root DSE?
What could i do next ?
Any help is very appreciated.
--
Gruß Axel
------------------------------
9 years, 4 months
unclean shutdown detected; attempting recovery - question
by frank.offermanns＠caseris.de
Hello,
I am using OpenLDAP 2.4.25.
After reboot I see logs (Logsetting -d 256) like :
=> bdb_idl_delete_key: c_del id failed: DB_LOCK_DEADLOCK: Locker killed to
resolve a deadlock (-30994)
I checked this and found that I can ignore this.
But one minute after this message OpenLDAP stopped working.
I automatically detected it and restarted OpenLDAP.
After restarting I see a logmessage:
hdb_db_open: database "o=mydomain": unclean shutdown detected; attempting
recovery.
Then I see for 1 to 3 minutes that OpenLDAP seems to work, before stopping
the work again.
I repeated restarting.
After the sixths restarts LDAP now seems to work correctly.
So now my question:
When I see the message: "unclean shutdown detected; attempting recovery"
How long does the recovery take? Is it possbile that the recovery was
still in progress as I restarted (after 5 mins) OpenLDAP?
Is there a Logsetting I could activate to see when the recovery is
finished?
Would it be better to manually do the recovery after stopping slapd?
Regards,
Frank
9 years, 4 months
Re: Ldap+Nfsv4+kerberos *nix / *bsd puzzle.
by Harry Coin
On 11/30/2011 7:23 AM, Juergen.Sprenger(a)swisscom.com wrote:
> Hi Harry,
>
> have done this here with an extended schema for a
> heterogeneous environment of AIX, HPUX, Solaris and Linux.
>
> Extended posixaccount to x-posixaccount with attributetypes (complete schema on request):
> 'x-homeDirectory'
> 'x-SolarishomeDirectory'
> 'x-AIXhomeDirectory'
> 'x-LinuxhomeDirectory'
> 'x-HPUXhomeDirectory'
>
> 'x-loginShell'
> 'x-SolarisloginShell'
> 'x-AIXloginShell'
> 'x-LinuxloginShell'
> 'x-HPUXloginShell'
>
> 'x-uidNumber'
> 'x-SolarisuidNumber'
> 'x-AIXuidNumber'
> 'x-LinuxuidNumber'
> 'x-HPUXuidNumber'
>
> 'x-gidNumber'
> 'x-SolarisgidNumber'
> 'x-AIXgidNumber'
> 'x-LinuxgidNumber'
> 'x-HPUXgidNumber'
>
> 'x-AIX5shadowLastChange'
> 'x-AIX5shadowMin'
> 'x-AIX5shadowMax'
> 'x-AIX5shadowWarning'
> 'x-AIX5shadowInactive'
> 'x-AIX5shadowExpire'
> 'x-AIX5shadowFlag'
>
> Objectclasses:
> 'x-posixAccount'
> 'x-shadowAccount'
> 'x-posixGroup'
>
> Then configure ldap clients with proper attribute mapping, example for Solaris:
> NS_LDAP_ATTRIBUTEMAP= passwd:uidNumber=x-SolarisuidNumber
> NS_LDAP_ATTRIBUTEMAP= passwd:gidNumber=x-SolarisgidNumber
> NS_LDAP_ATTRIBUTEMAP= passwd:homeDirectory=x-SolarishomeDirectory
> NS_LDAP_ATTRIBUTEMAP= passwd:loginSHell=x-SolarisloginShell
>
> Now each operating system can have its own uid/gid combination and shadow
> attributes for a given username.
>
> Disadvantage is, that You have slightly more complex users and You have to
> provide consistent settings on all machines of the same operating system.
>
> dn: uid=myname,ou=Person,dc=myEnterprise,dc=com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: x-posixAccount
> objectClass: shadowAccount
> sn: myname
> cn: myname
> uid: myname
> mail: myname(a)myEnterpsiem.com
> uidNumber: 287564
> gecos: myname
> displayName: myname
> x-LinuxuidNumber: 287564
> x-SolarisuidNumber: 287564
> x-HPUXuidNumber: 287564
> x-AIXuidNumber: 287564
> homeDirectory: /home/myname
> x-AIXhomeDirectory: /home/myname
> x-HPUXhomeDirectory: /home/myname
> x-LinuxhomeDirectory: /home/myname
> x-SolarishomeDirectory: /home/myname
> loginShell: /usr/bin/bash
> x-LinuxloginShell: /bin/bash
> x-HPUXloginShell: /bin/ksh
> x-SolarisloginShell: /usr/bin/bash
> x-AIXloginShell:: /bin/sh
> gidNumber: 50001
> x-HPUXgidNumber: 50001
> x-SolarisgidNumber: 50001
> x-LinuxgidNumber: 50001
> x-AIXgidNumber: 50001
> .
> .
> .
>
>
> Kind regards
>
> Juergen Sprenger
>
Juergen, thanks very much for this. I think your approach strikes a
balance between storing the same data in more than one place (separate
whole ou trees for each os duplicating other information -- at the
benefit of no schema changes), returning exactly the one result wanted
given a search (a practical necessity as those who aren't given to
maintain ldap clients like nslcd/nss_ldap are not able to cause them to
iterate through a number of home-directory results with the same name
looking for attributes to discern which is intended).
The downside of your approach is as you note no machine specific
variants, but those are few enough they can be put in the relevant
machine's passwd file and that set to be searched before ldap.
9 years, 4 months
How to synchornize in ldap? Please help.
by meena jain
Hi
I am new to ldap.
In my project , I need to send employee's information to the third party software.
For the first time set up , may be I can export the ldap data and push the information to the third party software but later I want to send delta changes. We don't want to write all employee changes every day.
How do I achieve this in ldap?
Meena
9 years, 4 months
CUCM search
by W.Siebert＠t-systems.com
> check your suffixmassage rules and compare to the rewritten suffix.
Sorry, now with the right congig bellow, suffixmassage and rewritten suffix matchs, but the problem still the same
-----------------------------------------------------------
Hello,
now I extended the schema and filter appears without of "?", but my problem still not solved:
slapd[20876]: ber_get_next on fd 8 failed errno=0 (Success)
slapd[20876]: connection_read(8): input error=-2 id=1001, closing. Nov 28 20:27:39 walrhel5
If I send the same search with various LDAP-Browsers (Softerra, LDP, Perlscript...), all is OK.
I tried witch OpenLDAP version: 2.4.26 and 2.4.28
FullLog:
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 fd=8 ACCEPT from IP=10.28.113.34:53476 (IP=0.0.0.0:389)
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: connection_get(8)
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: connection_get(8): got connid=1001
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: connection_read(8): checking for input on id=1001
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: op tag 0x60, time 1322601831
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 do_bind
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: >>> dnPrettyNormal: <cn=metaguru,dc=meta,dc=pov>
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: <<< dnPrettyNormal: <cn=metaguru,dc=meta,dc=pov>, <cn=metaguru,dc=meta,dc=pov>
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 BIND dn="cn=metaguru,dc=meta,dc=pov" method=128
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: do_bind: version=3 dn="cn=metaguru,dc=meta,dc=pov" method=128
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 meta_back_bind: dn="cn=metaguru,dc=meta,dc=pov".
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0: rootdn="cn=metaguru,dc=meta,dc=pov" bind succeeded
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 BIND dn="cn=metaguru,dc=meta,dc=pov" mech=SIMPLE ssf=0
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: do_bind: v3 bind: "cn=metaguru,dc=meta,dc=pov" to "cn=metaguru,dc=meta,dc=pov"
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: send_ldap_result: conn=1001 op=0 p=3
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: send_ldap_result: err=0 matched="" text=""
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: send_ldap_response: msgid=1 tag=97 err=0
Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 RESULT tag=97 err=0 text=
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: connection_get(8)
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: connection_get(8): got connid=1001
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: connection_read(8): checking for input on id=1001
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: op tag 0x63, time 1322601833
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 do_search
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: >>> dnPrettyNormal: <dc=meta,dc=pov>
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: <<< dnPrettyNormal: <dc=meta,dc=pov>, <dc=meta,dc=pov>
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: SRCH "dc=meta,dc=pov" 0 3
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: 0 0 0
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: AND
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter_list
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: EQUALITY
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: NOT
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: EQUALITY
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter_list
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: filter: (&(objectClass=user)(!(objectClass=computer)))
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: => get_ctrls
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical)
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: <= get_ctrls: n=1 rc=0 err=""
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: attrs:
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 SRCH base="dc=meta,dc=pov" scope=0 deref=3 filter="(&(objectClass=user)(!(objectClass=computer)))"
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1: meta_back_getconn[0]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1: meta_back_getconn[1]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_getconn: candidates=2 conn=ROOTDN fetched
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_back_search_start[0]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_search_dobind_init[0]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_search_dobind_init[0]=1
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='dc=meta,dc=pov'
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_rule_apply rule='((.+),)?dc=meta,[ ]?dc=pov$' string='dc=meta,dc=pov' [1 pass(es)]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'dc=spcdom,dc=udb'}
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchBase: "dc=meta,dc=pov" -> "dc=spcdom,dc=udb"
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='(&(objectClass=user)(!(objectClass=computer)))'
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'NULL'}
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchFilter: "(&(objectClass=user)(!(objectClass=computer)))" -> "(&(objectClass=user)(!(objectClass=computer)))"
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_back_search_start[0]=1
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_back_search_start[1]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_search_dobind_init[1]
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_search_dobind_init[1]=1
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='dc=meta,dc=pov'
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_rule_apply rule='((.+),)?dc=meta,[ ]?dc=pov$' string='dc=meta,dc=pov' [1 pass(es)] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'dc=metdom,dc=net'}
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchBase: "dc=meta,dc=pov" -> "dc=metdom,dc=net"
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='(&(objectClass=user)(!(objectClass=computer)))'
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'NULL'}
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchFilter: "(&(objectClass=user)(!(objectClass=computer)))" -> "(&(objectClass=user)(!(objectClass=computer)))"
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_back_search_start[1]=1
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_search: ncandidates=2 cnd="**"
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_search[0] match="" err=0.
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_search[1] match="" err=0.
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: send_ldap_result: conn=1001 op=1 p=3
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: send_ldap_result: err=0 matched="" text=""
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: send_ldap_response: msgid=2 tag=101 err=0
Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_get(8)
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_get(8): got connid=1001
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_read(8): checking for input on id=1001
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: op tag 0x42, time 1322601835
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: ber_get_next on fd 8 failed errno=0 (Success)
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_read(8): input error=-2 id=1001, closing.
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_closing: readying conn=1001 sd=8 for close
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_close: deferring conn=1001 sd=8
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: conn=1001 op=2 do_unbind
Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: conn=1001 op=2 UNBIND
Kind regards
Waldemar
-----Ursprüngliche Nachricht-----
Von: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it]
Gesendet: Dienstag, 29. November 2011 12:42
An: Siebert, Waldemar
Cc: openldap-technical(a)openldap.org
Betreff: Re: CUCM search
> Hello,
>
> I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD
> targets.
...
> Nov 28 20:27:39 walrhel5 slapd[7447]: filter:
> (&(?objectClass=user)(!(?objectClass=Computer)))
The objectClasses "user" and "computer" are unknown. They need to be defined in the proxy's schema.
p.
##########################################################################################
Hello,
I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD targets.
Cisco Unified Call Manager (CUCM) sends a rather simpy query:
(&(objectclass=user)(!(objectclass=Computer)))
If CUCM connects AD server directly, all is OK, gets a search result. But sending this search to Meta, does not work.
Log:
Nov 28 20:27:39 walrhel5 slapd[7447]: ber_get_next on fd 10 failed errno=0 (Success) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): input error=-2 id=1000, closing.
If I send the same search with various LDAP-Browsers (Softerra, LDP, Perlscript...), all is OK.
I tried witch OpenLDAP version: 2.4.26 and 2.4.28
My config:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/ts_ext.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
loglevel -1
#######################################################################
database meta
lastmod off
suffix "dc=meta,dc=pov"
rootdn "cn=metaguru,dc=meta,dc=pov"
rootpw Makaka77
uri "ldap://10.28.4.37:389/dc=meta,dc=pov"
suffixmassage "dc=meta,dc=pov" "dc=spcdom,dc=udb"
idassert-authzFrom "dn:*"
idassert-bind bindmethod=simple
binddn="cn=radiator,cn=Users,dc=spcdom,dc=udb"
credentials="Makaka77"
mode=none
uri "ldap://10.28.4.39:389/dc=meta,dc=pov"
suffixmassage "dc=meta,dc=pov" "dc=metdom,dc=net"
idassert-authzFrom "dn:*"
idassert-bind bindmethod=simple
binddn="cn=predator,cn=Users,dc=metdom,dc=net"
credentials="Makaka99"
mode=none
9 years, 4 months
Re: OpenLDAP 2.4.27 RPMs available on LTB-project
by Clément OUDOT
2011/11/28 Quanah Gibson-Mount <quanah(a)zimbra.com>:
> --On Friday, November 25, 2011 8:01 PM +0100 Clément OUDOT
> <clem.oudot(a)gmail.com> wrote:
>
>> 2011/11/25, Howard Chu <hyc(a)symas.com>:
>>>
>>> Clément OUDOT wrote:
>>>>
>>>> Hello,
>>>>
>>>> I built today RPMs for OpenLDAP 2.4.27, for those who are interested,
>>>> they are available here: http://ltb-project.org/wiki/download#openldap
>>>
>>> You are probably going to want to respin these with the last 3 commits in
>>> master.
>>> 26dc16e9f634ed5dc061088ff3bd156dec5170c0
>>> 2c4d548206916676026a5b57298ae3086500eb66
>>> 2a8b55b1c55cb99c09543f1b5648da98f5d28a8d
>>
>> Thanks for this information, do you plan to release 2.4.28 to include
>> these commits?
>
> Yes. It is out now.
Hi,
RPMs for OpenLDAP 2.4.28 are now available:
http://ltb-project.org/wiki/download#openldap
A new RPM has been created to provide overlays lastbind and smbk5pwd.
Clément.
9 years, 4 months
Re: CUCM search
by masarati＠aero.polimi.it
> Hello,
>
> I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD
> targets.
...
> Nov 28 20:27:39 walrhel5 slapd[7447]: filter:
> (&(?objectClass=user)(!(?objectClass=Computer)))
The objectClasses "user" and "computer" are unknown. They need to be
defined in the proxy's schema.
p.
9 years, 4 months
Read/Write Replication setup
by benoit
Hello,
I have setup a ldap replicate, replicating data from an offsite ldap
master. Replication is ok, but being a consumer replicate, my ldap server
is read only.
I need to add and modify attributes to this replicate, but i have no write
access to the master and ldap master admin won't change/update schemas...
>From the guide, i can't figure if it's possible.
Please, let me know what solution i have (on any Linux distro).
thanks
Ben,
9 years, 4 months
Trust between two server
by Raffael Sahli
Hi
I have a huge openldap server and a small one with maybe 10 users.
The small one contains it admistrator objects (or most of them are
admins) and is complitly different from the huge one.
So what I want is to include some userobjects or a specific basedn from
the small one in the huge one.
Im not sure whats the best way for that, maybe meta backend..? or some
proxy auth points to the small one..
dc=hugeldap,dc=com
|-ou=users
|-ou=admins
|->point to ldap://ldapserver.com?dc=smallldap,dc=net/memberof=hugeldap
Thanks for your help
--
Raffael Sahli
public(a)raffaelsahli.com
9 years, 4 months
