(ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu
Full_Name: Quanah Gibson-Mount
Version: 2.3.27/HEAD
OS: Linux 2.6 (64-bit)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.64.19.81)
The following core happened today on one of my replicas:
Core was generated by `/usr/local/lib/slapd -h ldap:///'.
Program terminated with signal 11, Segmentation fault.
(gdb) info threads
10 process 28453 0x00002b9d6da82e2c in pthread_join () from
/lib/libpthread.so.0
9 process 28455 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6
8 process 28456 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
7 process 28457 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
6 process 28458 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
5 process 28459 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
4 process 28462 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
3 process 28463 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
2 process 28464 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
* 1 process 28461 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6
(gdb) thread 10
[Switching to thread 10 (process 28453)]#0 0x00002b9d6da82e2c in pthread_join
() from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0
#1 0x0000000000425d41 in slapd_daemon () at daemon.c:2261
#2 0x0000000000416254 in main (argc=3, argv=0x7fffffd3c4c8) at main.c:854
(gdb) thread 9
[Switching to thread 9 (process 28455)]#0 0x00002b9d6dc62b2c in epoll_wait ()
from /lib/libc.so.6
(gdb) bt
#0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6
#1 0x0000000000425389 in slapd_daemon_task (ptr=0x6) at daemon.c:1859
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
#4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6
(gdb) thread 8
[Switching to thread 8 (process 28456)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
(gdb) thread 7
[Switching to thread 7 (process 28457)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
#4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6
(gdb) thread 6
[Switching to thread 6 (process 28458)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
(gdb) thread 5
[Switching to thread 5 (process 28459)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
#4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6
(gdb) thread 4
[Switching to thread 4 (process 28462)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
(gdb) thread 3
[Switching to thread 3 (process 28463)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
#4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6
(gdb) thread 2
[Switching to thread 2 (process 28464)]#0 0x00002b9d6da844e4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at
tpool.c:490
#2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
#4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6
(gdb) thread 1
[Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from
/lib/libc.so.6
(gdb) bt
#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6
#1 0x00002b9d6dc4dd22 in re_exec () from /lib/libc.so.6
#2 0x00002b9d6dc4b70b in re_exec () from /lib/libc.so.6
#3 0x00002b9d6dc49d83 in re_exec () from /lib/libc.so.6
#4 0x00002b9d6dc48526 in re_exec () from /lib/libc.so.6
#5 0x00002b9d6dc47e83 in re_exec () from /lib/libc.so.6
#6 0x00002b9d6dc474a6 in regexec () from /lib/libc.so.6
#7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080,
e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ,
state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874
#8 0x0000000000448521 in fe_access_allowed (op=0x2aaaafd40080,
e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ,
state=0x42e7d4e0, maskp=0x0) at acl.c:318
#9 0x0000000000443df3 in access_allowed_mask (op=0x2aaaafd40080,
e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ,
state=0x42e7d4e0, maskp=0x0) at acl.c:429
#10 0x0000000000436e1b in slap_send_search_entry (op=0x2aaaafd40080,
rs=0x42ffeeb0) at result.c:894
#11 0x00002b9d6f7342dc in hdb_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at
search.c:878
#12 0x000000000042a30a in fe_op_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at
search.c:355
#13 0x0000000000429c45 in do_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at
search.c:217
#14 0x000000000042837d in connection_operation (ctx=0x42fff020,
arg_v=0x2aaaafd40080) at connection.c:1100
#15 0x0000000000428a33 in connection_read_thread (ctx=0x42fff020, argv=0x0) at
connection.c:1227
#16 0x00002b9d6d03f522 in ldap_int_thread_pool_wrapper (xpool=0x1) at
tpool.c:478
#17 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so
#18 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0
Given that all threads except thread 1 appear to be in the same spot, I'm
guessing the problem is in thread 1.
Code is:
(gdb) frame 7
#7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080,
e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ,
state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874
874 if ( regexec( &a->acl_attrval_re,
val->bv_val, 0, NULL, 0 ) )
(gdb) l
869
870 if ( a->acl_attrval_style == ACL_STYLE_REGEX )
{
871 Debug( LDAP_DEBUG_ACL,
872 "acl_get: valpat %s\n",
873 a->acl_attrval.bv_val, 0, 0 );
874 if ( regexec( &a->acl_attrval_re,
val->bv_val, 0, NULL, 0 ) )
875 {
876 continue;
877 }
878
--Quanah
16 years, 11 months
(ITS#4696) Assert core in connection.c
by quanah＠stanford.edu
Full_Name: Quanah Gibson-Mount
Version: 2.3.27/HEAD
OS: Linux 2.6 (64-bit)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.64.19.81)
The following core occurred on one of my replica systems today:
(gdb) info threads
10 process 22650 0x00002b41c03a1e2c in pthread_join () from
/lib/libpthread.so.0
9 process 22652 0x00002b41c0581b2c in epoll_wait () from /lib/libc.so.6
8 process 22653 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
7 process 22654 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
6 process 22655 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
5 process 22663 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
4 process 22706 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
3 process 22707 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
2 process 22708 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
* 1 process 22705 0x00002b41c04de545 in raise () from /lib/libc.so.6
In particular:
[Switching to thread 1 (process 22705)]#3 0x00000000004271c5 in
connection_close (c=0x2b42c5088358) at connection.c:655
655 assert( c->c_writewaiter == 0);
(gdb) bt
#0 0x00002b41c04de545 in raise () from /lib/libc.so.6
#1 0x00002b41c04dfcce in abort () from /lib/libc.so.6
#2 0x00002b41c04d8362 in __assert_fail () from /lib/libc.so.6
#3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at
connection.c:655
#4 0x0000000000428a6c in connection_read_thread (ctx=0x42fff020, argv=0x68) at
connection.c:1391
#5 0x00002b41bf95e522 in ldap_int_thread_pool_wrapper (xpool=0x587a) at
tpool.c:478
#6 0x00002b41bf66fc93 in startMeUp () from /usr/local/lib/libhoard.so
#7 0x00002b41c03a0b55 in start_thread () from /lib/libpthread.so.0
#8 0x00002b41c05817f0 in clone () from /lib/libc.so.6
(gdb) frame 3
#3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at
connection.c:655
655 assert( c->c_writewaiter == 0);
(gdb) l
650 assert( connections != NULL );
651 assert( c != NULL );
652 assert( c->c_struct_state != SLAP_C_UNUSED );
653 assert( c->c_conn_state != SLAP_C_INVALID );
654 assert( LDAP_STAILQ_EMPTY(&c->c_ops) );
655 assert( c->c_writewaiter == 0);
656
657 /* only for stats (print -1 as "%lu" may give unexpected results
;) */
658 connid = c->c_connid;
659 close_reason = c->c_close_reason;
--Quanah
16 years, 11 months
Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by quanah＠stanford.edu
--On Wednesday, October 04, 2006 6:06 PM +0000 tim(a)dcs.qmul.ac.uk wrote:
> Full_Name: Tim Kay
> Version:
> OS: Linux (Fedora core 5 RPM)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (138.37.95.144)
>
>
> Modifying a DN on the syncrepl provider fails to propogate to the
> consumer. The provider "sends" a valid modify but the consumer, having
> received the modify request walks the tree, returns the parent DN to the
> entry, determines that write access is permitted and the iterates, at
> this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now
> searching for "�UUU" which looks like some unicode screw up.
You didn't provide an OpenLDAP version. I'll note that if you intend to
use syncrepl, use OpenLDAP 2.3.27 (or later).
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 11 months
(ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk
Full_Name: Tim Kay
Version:
OS: Linux (Fedora core 5 RPM)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (138.37.95.144)
Modifying a DN on the syncrepl provider fails to propogate to the consumer. The
provider "sends" a valid modify but the consumer, having received the modify
request walks the tree, returns the parent DN to the entry, determines that
write access is permitted and the iterates, at this point newSuperior->bv_val is
set to "*" !? bdb_dn2entry is now searching for "�UUU" which looks like
some unicode screw up.
Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: be_search (0)
Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry:
cn=laptT5,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk
Oct 4 17:38:37 auth1 slapd[2975]:
==>bdb_modrdn(cn=laptT2,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk,cn=laptT5,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk,*)
Oct 4 17:38:37 auth1 slapd[2975]:
bdb_dn2entry("cn=laptt2,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk")
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: wr to children of entry
ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk OK
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: parent
dn=ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: new parent "*" requested...
Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("�UUU")
Oct 4 17:38:37 auth1 slapd[2975]: => bdb_dn2id("")
Oct 4 17:38:37 auth1 slapd[2975]: <= bdb_dn2id: get failed: DB_NOTFOUND: No
matching key/data pair found (-30989)
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: newSup(ndn=�UUU) not
here!
Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: conn=-1 op=0 p=0
Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: err=32 matched="" text="new
superior not found"
Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: be_modrdn (32)
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify: dc=dcs,dc=qmul,dc=ac,dc=uk
Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("dc=dcs,dc=qmul,dc=ac,dc=uk")
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify_internal: 0x00000001:
dc=dcs,dc=qmul,dc=ac,dc=uk
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify_internal: replace contextCSN
Oct 4 17:38:37 auth1 slapd[2975]: => entry_encode(0x00000001):
dc=dcs,dc=qmul,dc=ac,dc=uk
Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify: updated id=00000001
dn="dc=dcs,dc=qmul,dc=ac,dc=uk"
Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: conn=-1 op=0 p=0
Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: err=0 matched="" text=""
16 years, 11 months
Re: (ITS#4691) syncrepl in refreshOnly dies when bind to provider fails
by bgmilne＠staff.telkomsa.net
--nextPart1470088.V9xMQ7mU2U
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Monday 02 October 2006 17:37, Howard Chu wrote:
> I don't see any indication of an OpenLDAP software bug here.
> Use the "retry" parameter if your connections are unreliable.
Since slapd.conf(5) isn't explicit on whether retry is valid for refreshOnl=
y=20
(I'll submit a patch for the documentation later), I had initially not set=
=20
retry when switching from refreshAndPersist, and when setting it subsequent=
ly=20
I had only added it back on one of the four databases.
I have subsequently set retry on all the databases, such that the syncrepl=
=20
configuration now looks as follows:
syncrepl rid=3D124
provider=3Dldaps://<master hostname>
retry=3D"60 10 300 10 600 +"
type=3DrefreshOnly
interval=3D"00:00:01:00"
searchbase=3D"<suffix>"
scope=3Dsub
attrs=3D"*"
schemachecking=3Doff
bindmethod=3Dsimple
binddn=3D"<dn for consumer>"
credentials=3D"<password for consumer>"
However, since restarting the consumer with this config, replication has=20
stopped again:
Oct 4 09:39:43 leda slapd2.3[28811]: syncrepl_entry: uid=3Dmail10015
Oct 4 09:39:44 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:39:44 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 09:39:58 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_INTERMEDIATE -=
=20
SYNC_ID_SET
Oct 4 09:39:59 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dtelkomdsl9953
Oct 4 09:39:59 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dtelkomsa122193
Oct 4 09:39:59 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dintekom37262
Oct 4 09:40:00 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dsusanna
Oct 4 09:40:01 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline139514
Oct 4 09:40:01 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline546691
Oct 4 09:40:02 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline193813
Oct 4 09:40:02 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dsusannas
Oct 4 09:40:02 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline457755
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline27380
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dti3345
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Dtelkomsa232906
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline555146
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline555146
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline566281
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: uid=3Dti3345
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline546691
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline193813
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dsusannas
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dtelkomdsl9953
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dintekom37262
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dtelkomsa122193
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0)
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline27899
Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0)
Oct 4 09:40:04 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 09:40:07 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 09:43:47 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed=
=20
(-1)
Oct 4 09:43:53 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed=
=20
(-1)
Oct 4 09:44:13 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed
(-1)
More bind failures occurred until:
Oct 4 10:38:54 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed=
=20
(-1)
after which there was only:
Oct 4 10:40:15 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 10:40:46 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 10:41:15 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
[...]
Oct 4 17:24:14 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 17:24:46 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT
After a restart:
Oct 4 17:25:54 leda slapd2.3[28811]: daemon: shutdown requested and=20
initiated.
Oct 4 17:26:26 leda slapd2.3[30580]: slapd starting
Oct 4 17:26:26 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 17:26:26 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 4 17:26:28 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_INTERMEDIATE -=
=20
SYNC_ID_SET
Oct 4 17:26:29 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_INTERMEDIATE -=
=20
SYNC_ID_SET
Oct 4 17:26:45 leda slapd2.3[30580]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline185588
Oct 4 17:26:46 leda slapd2.3[30580]: syncrepl_del_nonpresent: be_delete=20
uid=3Donline193883
(In these log extracts, the DN's have been truncated for privacy reasons)
This doesn't occur on any of the slaves in our production site, but I will =
see=20
if I can reproduce it via other means.
Regards,
Buchan
=2D-=20
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
--nextPart1470088.V9xMQ7mU2U
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBFI9borJK6UGDSBKcRAvE/AJ44a1QsX/zY66CpkGzJkbfeFHm/kwCdHUyl
/uTp0anElaKJZ21EXkeaGO0=
=q/t2
-----END PGP SIGNATURE-----
--nextPart1470088.V9xMQ7mU2U--
16 years, 11 months
(ITS#4694) syncrepl in refreshOnly dies when bind to provider gails
by bgmilne＠staff.telkomsa.net
Full_Name: Buchan Milne
Version: 2.3.27
OS: Linux 2.4 (RHEL 3)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (196.15.129.131)
One of our replicas sits on the other side of a relatively congested WAN link
(with multiple firewalls in between, which I have no control over).
Since switching to syncrepl, it has been difficult to achieve a configuration
that supports replication reliably to any extent.
Using syncrepl consumer configuration with:
syncrepl rid=124
provider=ldaps://<master hostname>
type=refreshOnly
interval="00:00:01:00"
searchbase="<suffix>"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="<dn for consumer>"
credentials="<password for consumer>"
I see replication dies frequently, it seems to occur when (for whatever reason)
the consumer fails to bind:
ct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: uid=lere1
Oct 2 12:03:37 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:03:43 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=deleted/telkomsa133309,ou=radius,o=intekom,c=za (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=telkomsa158118
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online517446
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online517446
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa158118
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online564666
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=telkomsa220585
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online188476
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=mail109585
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa196118
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online313812
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online519355
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=online536857
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa233527
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564379
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564667
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=ihatechromium
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online556601
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online519355
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online519355
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online556601
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online564667
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online534772
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online18609
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=online188476
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=telkomdsl56797
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=hotkaj
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=magda22
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:05:41 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online561383
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online534772
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: uid=online561383
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:06:27 leda slapd2.3[1332]: do_syncrep1: ldap_sasl_bind_s failed (-1)
16 years, 11 months
Re: (ITS#4693) Unnecessary licensing statement in core.schema?
by Kurt＠OpenLDAP.org
At 11:25 AM 10/3/2006, quanah(a)stanford.edu wrote:
>Full_Name: Quanah Gibson-Mount
>Version: All
>OS: NA
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (171.66.155.86)
Nothing in this message should be construed or represented
as as legal advice to any party.
Recent versions of this file (and numerous other files comprising
OpenLDAP Software) have contained material copied (with or
without modification) from various ISOC-published documents,
namely RFCs and I-Ds. It is the OpenLDAP Foundation current
policy and practice to include notices from the source documents
even where OpenLDAP Foundation believe the nature of our copying
is not subject to any license. The inclusion of this notice in
recent revisions of this file (including both 1.88 and 1.89)
is consistent with the current policy and practice and, hence,
is not to be removed.
This report should be closed as no further action is required
or appropriate.
Regards, Kurt (as Executive Director of the OpenLDAP Foundation)
16 years, 11 months
Re: (ITS#4693) Unnecessary licensing statement in core.schema?
by quanah＠stanford.edu
--On Tuesday, October 03, 2006 6:25 PM +0000 openldap-its(a)OpenLDAP.org
wrote:
Follow-on note:
note that a literal reading of the current license would say that you're
not allowed to modify
the schema on your local system unless you write a completely new schema
from scratch without referring to that one.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 11 months
(ITS#4693) Unnecessary licensing statement in core.schema?
by quanah＠stanford.edu
Full_Name: Quanah Gibson-Mount
Version: All
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)
The core.schema file has the following included in it:
## Portions Copyright (C) The Internet Society (1997-2003).
## All Rights Reserved.
##
## This document and translations of it may be copied and furnished to
## others, and derivative works that comment on or otherwise explain it
## or assist in its implementation may be prepared, copied, published
## and distributed, in whole or in part, without restriction of any
## kind, provided that the above copyright notice and this paragraph are
## included on all such copies and derivative works. However, this
## document itself may not be modified in any way, such as by removing
## the copyright notice or references to the Internet Society or other
## Internet organizations, except as needed for the purpose of
## developing Internet standards in which case the procedures for
## copyrights defined in the Internet Standards process must be
## followed, or as required to translate it into languages other than
## English.
##
## The limited permissions granted above are perpetual and will not be
## revoked by the Internet Society or its successors or assigns.
##
## This document and the information contained herein is provided on an
## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This is causing some unhappiness from the Debian folks, but their final
conclusion is that core.schema is not copyrightable under US law:
[snip email 1]
> Doesn't the copyright in question apply to the RFC only? AFAICS,
> core.schema basically reads:
> 1. Part of OpenLDAP, with the following license:
> 2. OpenLDAP license (see license.html)
> 3. Based on an RFC, with the following license:
> 4. RFC license
> 5. Specific RFC attributions
> 6. The schema itself
[snip email 2]
> Plus, this is an interface specification if I've ever seen one, and
> interface specifications are not copyrightable under US law.
[snip email 3]
> If this file is a non-copyrightable interface definition, the bug here is
> the presence of a copyright notice and license statement where there should
> be none.
If these are correct, then shouldn't this license actually be removed from
core.schema?
--Quanah
16 years, 11 months
