Re: (ITS#5295) option to allow slapd bind to any available port
by hyc＠symas.com
chitrav(a)us.ibm.com wrote:
> Full_Name: Chitra Vemkatramani
> Version: 2.3.27
> OS: Redhat
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (162.83.178.28)
> For a project that we are using openldap in, we would like to allow multiple
> users to start up ldap servers on the same machine. We would like an option on
> the slapd command line asking the server to pick any available port to bind to.
> We can then do netstat, find the port and pass that on to the client. Here is
> the patch we put in, to allow us to specify -1 for the port, so that the server
> will pick any available port. Can you please consider adding this to the server
> options ?
Hacking the server code to support your peculiar disorganization doesn't seem
like a good idea. Just have your users agree on the port numbers they'll each use.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 9 months
Re: (ITS#5296) Search netgroup by triple don't report existing entry
by hyc＠symas.com
rochette_jean-louis(a)emc.com wrote:
> Full_Name: Jean-Louis ROCHETTE
> Version: 2.3.39
> OS: Linux Fedora
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (152.62.109.163)
>
>
> Brief description of the problem
> --------------------------------
> Lookup of a netgroup by triple doesn't work in last stable release slapd 2.3.39,
> though it worked well with slapd 2.3.27.
> This looks like a regression in slapd.
> This should be easy to reproduce.
> The problem was first noticed in slapd 2.3.30.
> The lookup by triple succeeds with a iPlanet server.
There are no matching rules defined for nisNetgroupTriple in nis.schema. There
have never been, since RFC2307 doesn't define any. As such, filtering by
nisNetgroupTriple is totally undefined. Any server that returns your expected
result using the search filter you provide is broken.
There is no regression here. Your distro vendor may have hacked their own
schema files to provide one, that's an issue for you to discuss with your
vendor. This ITS will be closed.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 9 months
Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by quanah＠zimbra.com
--On December 21, 2007 8:17:40 PM +0000 rra(a)stanford.edu wrote:
> Is there any further thoughts on this ITS? It's still open and it doesn't
> look like the patch has been applied, but it seemed like we'd reached a
> conclusion that it was the right thing to do.
This is now fixed in HEAD and 2.4.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 9 months
Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu
Is there any further thoughts on this ITS? It's still open and it doesn't
look like the patch has been applied, but it seemed like we'd reached a
conclusion that it was the right thing to do.
To recap, the problem is that libldap_r isn't being linked with the
threading libraries, which means that when the linker builds the shared
library, it doesn't have symbol versioning information available for the
pthread functions and creates unversioned references. If the current ABI
of the functions ever changes (as has happened in the past with glibc on
Alpha), segfaults and other unpleasantness result.
The patch adds the threading libraries to the link command for libldap_r
so that the linker has the symbol versioning information available and can
bind the pthread functions to the appropriate symbol versions in glibc,
allowing the library to keep working using glibc's backwards compatibility
support even if the current ABI changes again.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
15 years, 9 months
Re: (ITS#5296) Search netgroup by triple don't report existing entry
by quanah＠zimbra.com
Please verify if this issue occurs in OpenLDAP 2.4.7. Thanks.
--Quanah
--On December 21, 2007 11:37:38 AM +0000 rochette_jean-louis(a)emc.com wrote:
> Full_Name: Jean-Louis ROCHETTE
> Version: 2.3.39
> OS: Linux Fedora
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (152.62.109.163)
>
>
> Brief description of the problem
> --------------------------------
> Lookup of a netgroup by triple doesn't work in last stable release slapd
> 2.3.39, though it worked well with slapd 2.3.27.
> This looks like a regression in slapd.
> This should be easy to reproduce.
> The problem was first noticed in slapd 2.3.30.
> The lookup by triple succeeds with a iPlanet server.
>
>
> Details
> -------
> Let's define a host, and a netgroup with a single triple designating this
> host:
>
> dn: cn=r2d2,ou=Hosts,dc=devldapdom1,dc=lcsc
> objectClass: top
> objectClass: ipHost
> objectClass: device
> ipHostNumber: 192.168.5.69
> cn: r2d2
>
> dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
> objectClass: top
> objectClass: nisNetgroup
> cn: r2d2netg
> description: netgroup r2d2netg to test AR 98216
> nisNetgroupTriple: (r2d2,,)
>
> The syntax for the nisNetgroupTriple attribute is IA5String (instead of
> Netgroup Triple):
> attributeTypes: ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup
> triple' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>
>
> 1) *** Test with slapd 2.3.27 : OK ***
> jlr@SUSE-LDAP1(53) uname -a
> Linux SUSE-LDAP1 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006
> i686 i686 i386 GNU/Linux
> jlr@SUSE-LDAP1(42) ps -ef |grep slap
> ldap 3774 1 0 Nov29 ? 00:04:47 /usr/lib/openldap/slapd -h
> ldap:/// -u ldap -g ldap -o slp=on
> jlr@SUSE-LDAP1(45) /usr/lib/openldap/slapd -V
> @(#) $OpenLDAP: slapd 2.3.27 (Nov 25 2006 17:08:16) $
>
> abuild@eisler:/usr/src/packages/BUILD/openldap-2.3.27/servers/slapd
> jlr@SUSE-LDAP1(46) ldapsearch -V
> ldapsearch: @(#) $OpenLDAP: ldapsearch 2.3.27 (Nov 25 2006 17:09:14) $
> abuild@dale:/usr/src/packages/BUILD/openldap-2.3.27/clients/tools
> (LDAP library: OpenLDAP 20327)
>
> // locate the netgroup by name -> find r2d2netg with triple (r2d2,,) : OK
> jlr@SUSE-LDAP1(49) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc"
> -s one "(&(objectClass=nisNetgroup)(cn=r2d2netg))" cn nisNetgroupTriple
># extended LDIF
>#
># LDAPv3
># base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
># filter: (&(objectClass=nisNetgroup)(cn=r2d2netg))
># requesting: cn nisNetgroupTriple
>#
>
># r2d2netg, netgroup, devldapdom1.lcsc
> dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
> cn: r2d2netg
> nisNetgroupTriple: (r2d2,,)
>
># search result
> search: 2
> result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
> // locate the netgroup by triple -> found too, ok.
> jlr@SUSE-LDAP1(52) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc"
> -s one "(&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))" cn
># extended LDIF
>#
># LDAPv3
># base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
># filter: (&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))
># requesting: cn
>#
>
># r2d2netg, netgroup, devldapdom1.lcsc
> dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
> cn: r2d2netg
>
># search result
> search: 2
> result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>
> 2) *** Test with slapd 2.3.39 : PROBLEM ***
> jlr@newlnxjlr(19) uname -a
> Linux newlnxjlr 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006
> i686 i686 i386 GNU/Linux
> jlr@newlnxjlr(17) ps -ef |grep slap
> ldap 4684 1 0 Dec20 ? 00:00:00 /usr/sbin/slapd -h
> ldap:/// -u ldap
> jlr@newlnxjlr(18) /usr/sbin/slapd -V
> @(#) $OpenLDAP: slapd 2.3.39 (Dec 20 2007 17:00:06) $
> jlr@newlnxjlr:/tmp/openldap-2.3.39/servers/slapd
> jlr@newlnxjlr(20) ldapsearch -V
> ldapsearch: @(#) $OpenLDAP: ldapsearch 2.3.39 (Dec 20 2007 16:58:50) $
> jlr@newlnxjlr:/tmp/openldap-2.3.39/clients/tools
> (LDAP library: OpenLDAP 20339)
> // this server is a replicate of previous one
>
> // locate the netgroup by name -> find r2d2netg with triple (r2d2,,) : OK
> jlr@newlnxjlr(24) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc"
> -s one "(&(objectClass=nisNetgroup)(cn=r2d2netg))" cn nisNetgroupTriple
># extended LDIF
>#
># LDAPv3
># base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
># filter: (&(objectClass=nisNetgroup)(cn=r2d2netg))
># requesting: cn nisNetgroupTriple
>#
>
># r2d2netg, netgroup, devldapdom1.lcsc
> dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
> cn: r2d2netg
> nisNetgroupTriple: (r2d2,,)
>
># search result
> search: 2
> result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
> // locate the netgroup by triple -> NOT FOUND? PROBLEM.
> jlr@newlnxjlr(25) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc"
> -s one "(&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))" cn
># extended LDIF
>#
># LDAPv3
># base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
># filter: (&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))
># requesting: cn
>#
>
># search result
> search: 2
> result: 0 Success
>
># numResponses: 1
>
> // eof
>
>
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 9 months
Re: (ITS#5297) I have a problem when I switch authldap.schema
by quanah＠zimbra.com
Usage questions should be sent to openldap-software(a)openldap.org
--Quanah
--On December 21, 2007 1:01:59 PM +0000 bsdrab(a)gmail.com wrote:
> Full_Name: Nikolay G. Petrov
> Version: 24
> OS: FreeBSD 7.0-BETA2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.125.204.194)
>
>
> I have a problem with my ldap server. When I discribe path to
> authldap.schema in slapd.conf, after restart slapd, sirver didn't to up.
>
>
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 9 months
(ITS#5296) Search netgroup by triple don't report existing entry
by rochette_jean-louis＠emc.com
Full_Name: Jean-Louis ROCHETTE
Version: 2.3.39
OS: Linux Fedora
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (152.62.109.163)
Brief description of the problem
--------------------------------
Lookup of a netgroup by triple doesn't work in last stable release slapd 2.3.39,
though it worked well with slapd 2.3.27.
This looks like a regression in slapd.
This should be easy to reproduce.
The problem was first noticed in slapd 2.3.30.
The lookup by triple succeeds with a iPlanet server.
Details
-------
Let's define a host, and a netgroup with a single triple designating this host:
dn: cn=r2d2,ou=Hosts,dc=devldapdom1,dc=lcsc
objectClass: top
objectClass: ipHost
objectClass: device
ipHostNumber: 192.168.5.69
cn: r2d2
dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
objectClass: top
objectClass: nisNetgroup
cn: r2d2netg
description: netgroup r2d2netg to test AR 98216
nisNetgroupTriple: (r2d2,,)
The syntax for the nisNetgroupTriple attribute is IA5String (instead of Netgroup
Triple):
attributeTypes: ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup
triple' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1) *** Test with slapd 2.3.27 : OK ***
jlr@SUSE-LDAP1(53) uname -a
Linux SUSE-LDAP1 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 i686
i686 i386 GNU/Linux
jlr@SUSE-LDAP1(42) ps -ef |grep slap
ldap 3774 1 0 Nov29 ? 00:04:47 /usr/lib/openldap/slapd -h
ldap:/// -u ldap -g ldap -o slp=on
jlr@SUSE-LDAP1(45) /usr/lib/openldap/slapd -V
@(#) $OpenLDAP: slapd 2.3.27 (Nov 25 2006 17:08:16) $
abuild@eisler:/usr/src/packages/BUILD/openldap-2.3.27/servers/slapd
jlr@SUSE-LDAP1(46) ldapsearch -V
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.3.27 (Nov 25 2006 17:09:14) $
abuild@dale:/usr/src/packages/BUILD/openldap-2.3.27/clients/tools
(LDAP library: OpenLDAP 20327)
// locate the netgroup by name -> find r2d2netg with triple (r2d2,,) : OK
jlr@SUSE-LDAP1(49) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc" -s one
"(&(objectClass=nisNetgroup)(cn=r2d2netg))" cn nisNetgroupTriple
# extended LDIF
#
# LDAPv3
# base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
# filter: (&(objectClass=nisNetgroup)(cn=r2d2netg))
# requesting: cn nisNetgroupTriple
#
# r2d2netg, netgroup, devldapdom1.lcsc
dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
cn: r2d2netg
nisNetgroupTriple: (r2d2,,)
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
// locate the netgroup by triple -> found too, ok.
jlr@SUSE-LDAP1(52) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc" -s one
"(&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))" cn
# extended LDIF
#
# LDAPv3
# base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
# filter: (&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))
# requesting: cn
#
# r2d2netg, netgroup, devldapdom1.lcsc
dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
cn: r2d2netg
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
2) *** Test with slapd 2.3.39 : PROBLEM ***
jlr@newlnxjlr(19) uname -a
Linux newlnxjlr 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 i686
i386 GNU/Linux
jlr@newlnxjlr(17) ps -ef |grep slap
ldap 4684 1 0 Dec20 ? 00:00:00 /usr/sbin/slapd -h ldap:/// -u
ldap
jlr@newlnxjlr(18) /usr/sbin/slapd -V
@(#) $OpenLDAP: slapd 2.3.39 (Dec 20 2007 17:00:06) $
jlr@newlnxjlr:/tmp/openldap-2.3.39/servers/slapd
jlr@newlnxjlr(20) ldapsearch -V
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.3.39 (Dec 20 2007 16:58:50) $
jlr@newlnxjlr:/tmp/openldap-2.3.39/clients/tools
(LDAP library: OpenLDAP 20339)
// this server is a replicate of previous one
// locate the netgroup by name -> find r2d2netg with triple (r2d2,,) : OK
jlr@newlnxjlr(24) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc" -s one
"(&(objectClass=nisNetgroup)(cn=r2d2netg))" cn nisNetgroupTriple
# extended LDIF
#
# LDAPv3
# base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
# filter: (&(objectClass=nisNetgroup)(cn=r2d2netg))
# requesting: cn nisNetgroupTriple
#
# r2d2netg, netgroup, devldapdom1.lcsc
dn: cn=r2d2netg,ou=netgroup,dc=devldapdom1,dc=lcsc
cn: r2d2netg
nisNetgroupTriple: (r2d2,,)
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
// locate the netgroup by triple -> NOT FOUND? PROBLEM.
jlr@newlnxjlr(25) ldapsearch -x -b "ou=netgroup,dc=devldapdom1,dc=lcsc" -s one
"(&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))" cn
# extended LDIF
#
# LDAPv3
# base <ou=netgroup,dc=devldapdom1,dc=lcsc> with scope oneLevel
# filter: (&(objectClass=nisNetgroup)(nisNetgroupTriple=\(r2d2,,\)))
# requesting: cn
#
# search result
search: 2
result: 0 Success
# numResponses: 1
// eof
15 years, 9 months
syncrepl (refreshAndPersist) fails after system date is moved backwards
by jan.cedergren＠nsn.com
Hello,
I'm facing some problems with replication and hoping that someone could
clarify how this case should work (is this a bug or a feature).
Replication seems to work initially as expected but if I change the
system date to something in the past (e.g. 1 year backwards)
then the replication stops working. When I change back the current date
(to the year that it initially was) then everything seems
to work fine again.
Is this kind of behaviour in LDAP a restriction that has to do with
having timestamps in the CSNs or is this a bug? I tried to find this
problem from the archives with no success.
Br,
-Jani
15 years, 9 months
