Re: (ITS#6962) Download down?
by h.b.furuseth@usit.uio.no
h.b.furuseth(a)usit.uio.no writes:
>demian.djrn(a)gmail.com writes:
>> all mirrors are down, i can't download the program.
>
> The mirror list needs to be updated. These are down or obsolete:
>
> Costa Rica: No /openldap directory.
Still missing in the directory listing at <http://mirrors.ucr.ac.cr/>.
> Italy: Unknown host it.openldap.org.
> Korea: No route to host ftp.holywar.net; TTL exceeded.
> Portugal: Last update was in 2008.
I notice these have been removed from the mirror list now.
--
Hallvard
11 years, 5 months
(ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by dieter@dkluenter.de
Full_Name: Dieter Kluenter
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.38.5.243)
slapd crashes with segmentation fault on a slapo-dds refresh operation, if
syncprov is enabled and configured
(gdb) bt
#0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530,
maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59
#1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at syncprov.c:1793
#2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:505
#3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:580
#4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:915
#5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at
extended.c:237
#6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at
extended.c:177
#7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60,
arg_v=0x7f01d8013530) at connection.c:1138
#8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10)
at connection.c:1274
#9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at
tpool.c:685
#10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at
pthread_create.c:297
#11 0x00007f01f3c1166d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x0000000000000000 in ?? ()
(gdb) frame 0
#0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530,
maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59
59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) {
(gdb) frame 1
#1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at syncprov.c:1793
1793 slap_get_commit_csn( op, &maxcsn, &foundit );
(gdb) frame 2
#2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:505
505 rc = op->o_callback->sc_response( op, rs );
(gdb) frame 3
#3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:580
580 rc = slap_response_play( op, rs );
(gdb)
-Dieter
11 years, 5 months
(ITS#7101) test001 no longer supports back-ldif
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version: 2.4.28
OS:
URL:
Submission from: (NULL) (193.71.61.60)
Submitted by: hallvard
test001-slapadd now breaks with back-ldif, since it uses
unordered slapadd which back-ldif does not support.
Also 'rm -f $DBDIR1/*' should be 'rm -rf' for back-ldif.
11 years, 5 months
Re: (ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by hyc@symas.com
nick(a)eurobjects.com wrote:
> Full_Name: Nikolaos Milas
> Version: 2.4.26 (LTB RPM)
> OS: CentOS 5.7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.251.204.222)
>
>
> We use the following schema (among others):
Thanks for the report, this is now fixed in git master.
>
> DN: cn={5}postfix,cn=schema,cn=config
> objectClass: olcSchemaConfig
> cn: {5}postfix
> olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid'
> DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines
> the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC
> 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A
> flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
> olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC
> 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $
> mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) )
> olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual
> account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid
> $ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) )
> olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email
> account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY (
> mailacceptinggeneralid $ aliasInactive ) )
> olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox
> for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description )
>
> We run:
> # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
> "cn=admin,cn=config" -f /root/work/schemachange1
>
> where /root/work/schemachange1:
> dn: cn={5}postfix,cn=schema,cn=config
> changetype: modify
> delete: olcAttributeTypes
> olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid'
> DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> -
> add: olcAttributeTypes
> olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC
> 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>
> This is successful:
> [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
> "cn=admin,cn=config" -f /root/work/schemachange1
> ldap_initialize( ldap://localhost )
> Enter LDAP Password:
> delete olcAttributeTypes:
> {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines
> an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> add olcAttributeTypes:
> {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines
> an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> modifying entry "cn={5}postfix,cn=schema,cn=config"
> modify complete
>
> However, then we try to run:
> # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
> "cn=admin,cn=config" -f /root/work/schemachange2
>
> where /root/work/schemachange2:
> dn: cn={5}postfix,cn=schema,cn=config
> changetype: modify
> delete: olcAttributeTypes
> olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines
> the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> -
> add: olcAttributeTypes
> olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the
> address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>
> and this causes an OpenLDAP crash:
> [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
> "cn=admin,cn=config" -f /root/work/schemachange2
> ldap_initialize( ldap://localhost )
> Enter LDAP Password:
> delete olcAttributeTypes:
> {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address
> mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> add olcAttributeTypes:
> {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address
> mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> modifying entry "cn={5}postfix,cn=schema,cn=config"
>
> This hangs, and we interrupt with Ctrl-C.
>
> gdb reports:
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 6 months
Re: (ITS#7099) slapadd segfaults with back-mdb and slapo-dds
by hyc@symas.com
dieter(a)dkluenter.de wrote:
> Full_Name: Dieter Kluenter
> Version:
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (141.38.5.243)
>
>
> back-mdb tries to read entry databases prior to initialisation, which leeds to
> segmatation fault
slapo-dds was misbehaving, fixed now in master. Overlays that hook the db_open
entry point are required to check for (slapMode & SLAP_TOOL_MODE) and exit as
a no-op in that case. slapo-dds was not doing this. It caused slapcat to crash
as well.
This problem was triggered by using the dds-max_dynamocObjects setting, which
makes slapo-dds fire off a search at startup to find entries to expire/delete.
Of course this operation fails in slapcat anyway, since the database is opened
read-only.
>
> output of slapadd -d-1
> [...]
> 4ed4888e slapadd startup: initiated.
> 4ed4888e backend_startup_one: starting "o=avci,c=de"
> 4ed4888e mdb_db_open: "o=avci,c=de"
> 4ed4888e mdb_db_open: database "o=avci,c=de":
> dbenv_open(/home/dieter/openldap/var/ldap-dds).
> 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))"
> 4ed4888e begin get_filter
> 4ed4888e AND
> 4ed4888e begin get_filter_list
> 4ed4888e begin get_filter
> 4ed4888e EQUALITY
> 4ed4888e end get_filter 0
> 4ed4888e begin get_filter
> 4ed4888e LE
> 4ed4888e end get_filter 0
> 4ed4888e end get_filter_list
> 4ed4888e end get_filter 0
> Speicherzugriffsfehler
>
> the appropriate slapo-dds configuration:
> [...]
> overlay dds
> dds-max-ttl 86400
> dds-min-ttl 0
> dds-default-ttl 3600
> dds-interval 1800
> dds-tolerance 60
> dds-max-dynamicObjects 100
> dds-state TRUE
> [...]
>
> -Dieter
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 6 months
Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by michael@stroeder.com
Pierangelo Masarati wrote:
> Good point. I overlooked this in my original interpretation. I'll look into
> this, time permitting. Thanks, p.
Take your time. Nothing urgent. I'm just playing with it for interop testing
(refresh operation and plugin classes in web2ldap).
Ciao, Michael.
11 years, 6 months
Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by masarati@aero.polimi.it
On 11/29/2011 02:34 PM, michael(a)stroeder.com wrote:
> Full_Name:
> Version:
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.15.82)
>
>
> As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a
> dynamicObject entry. But slapo-dds always returns the same value for entryTTL
> (last refreshTTL). Another server implementation returns decreasing values for
> entryTTL which would be IMO the correct behaviour.
Good point. I overlooked this in my original interpretation. I'll look
into this, time permitting. Thanks, p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano
11 years, 6 months
(ITS#7100) slapo-dds: entryTTL not decreasing
by michael@stroeder.com
Full_Name:
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.163.15.82)
As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a
dynamicObject entry. But slapo-dds always returns the same value for entryTTL
(last refreshTTL). Another server implementation returns decreasing values for
entryTTL which would be IMO the correct behaviour.
11 years, 6 months
Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by hyc@symas.com
paul(a)scom.ca wrote:
> Full_Name: Paul Kudla
> Version: 2.4.23& 2.4.28
> OS: Freebsd 8.2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (69.171.154.78)
>
>
> Simply put openldap will not configure
>
> How do i get it to find the sql.h file
>
> checking number of arguments of ctime_r... 2
> checking number of arguments of gethostbyname_r... 6
> checking number of arguments of gethostbyaddr_r... 8
> checking for openlog... yes
> checking sql.h usability... no
> checking sql.h presence... no
> checking for sql.h... no
> configure: error: could not locate SQL headers
>
> installed UnixODBC version unixODBC-2.3.1
>
>
> [00:28:54] root@ldap /usr/local/src/openldap-2.4.23
> # ll /usr/local/include/sql.h
> -rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h
>
> [00:34:18] root@ldap /usr/local/src/openldap-2.4.23
> #
>
> this issue googles alot without any clear explanation.
>
> have no problem contributing to the cause - let me know how.
Read the INSTALL document. Set the CPPFLAGS variable correctly.
No bug here, closing this ITS.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 6 months
(ITS#7099) slapadd segfaults with back-mdb and slapo-dds
by dieter@dkluenter.de
Full_Name: Dieter Kluenter
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.38.5.243)
back-mdb tries to read entry databases prior to initialisation, which leeds to
segmatation fault
output of slapadd -d-1
[...]
4ed4888e slapadd startup: initiated.
4ed4888e backend_startup_one: starting "o=avci,c=de"
4ed4888e mdb_db_open: "o=avci,c=de"
4ed4888e mdb_db_open: database "o=avci,c=de":
dbenv_open(/home/dieter/openldap/var/ldap-dds).
4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))"
4ed4888e begin get_filter
4ed4888e AND
4ed4888e begin get_filter_list
4ed4888e begin get_filter
4ed4888e EQUALITY
4ed4888e end get_filter 0
4ed4888e begin get_filter
4ed4888e LE
4ed4888e end get_filter 0
4ed4888e end get_filter_list
4ed4888e end get_filter 0
Speicherzugriffsfehler
the appropriate slapo-dds configuration:
[...]
overlay dds
dds-max-ttl 86400
dds-min-ttl 0
dds-default-ttl 3600
dds-interval 1800
dds-tolerance 60
dds-max-dynamicObjects 100
dds-state TRUE
[...]
-Dieter
11 years, 6 months