openldap-bugs December 2009

openldap-bugs@openldap.org

28 participants
133 discussions

(ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 02 Dec '09

02 Dec '09

Full_Name: Jarbas Peixoto Junior Version: 2.4.11 / 2.4.17 / 2.4.20 OS: Gnu/Linux Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.152.34.143) Possible bug in Overlay pPolicy I have OpenLDAP installed via the Debian Lenny package functioning normally. Aiming to test the version of Debian Squeeze in the test machine installed package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). However, when testing the overlay pPolicy noticed that a wrong password authentication, runs all objects in the ldap database, causing a "delay" that does not exist in version Lenny. Below is some information that may be useful in detecting the problem: File: slapd.conf ==================== moduleload ppolicy overlay ppolicy ppolicy_default "cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br" ppolicy_use_lockout ==================== ldapsearch -LLL -x -H ldap://squeeze -b ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br '(cn=default)' dn: cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,d c=br objectClass: top objectClass: device objectClass: pwdPolicy pwdAttribute: userPassword description:: UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M= pwdAllowUserChange: TRUE pwdFailureCountInterval: 3600 pwdGraceAuthNLimit: 5 pwdInHistory: 0 pwdLockoutDuration: 60 pwdMaxAge: 7776000 pwdMinAge: 0 pwdMinLength: 6 pwdSafeModify: FALSE pwdCheckQuality: 1 pwdExpireWarning: 600 cn: default pwdMustChange: FALSE pwdMaxFailure: 10 pwdLockout: FALSE date ; ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br -D uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp ; date Qua Dez 2 16:14:56 AMST 2009 ldap_bind: Invalid credentials (49) Qua Dez 2 16:15:36 AMST 2009 ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp dn: uid=jarbas.peixoto,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br mail: jarbas.peixoto(a)previdencia.gov.br cn: Jarbas Peixoto Junior pwdAccountLockedTime: 20091202161422Z pwdFailureTime: 20091202162324Z pwdFailureTime: 20091202162805Z pwdFailureTime: 20091202162925Z pwdFailureTime: 20091202164558Z pwdFailureTime: 20091202164702Z pwdFailureTime: 20091202165016Z pwdFailureTime: 20091202181310Z pwdFailureTime: 20091202182914Z pwdFailureTime: 20091202183248Z pwdFailureTime: 20091202190153Z pwdFailureTime: 20091202191147Z pwdFailureTime: 20091202191544Z pwdFailureTime: 20091202191644Z modifyTimestamp: 20091202191724Z date ; ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br -D uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp ; date Qua Dez 2 16:19:03 AMST 2009 ldap_bind: Invalid credentials (49) Qua Dez 2 16:19:44 AMST 2009 ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp dn: uid=jarbas.peixoto,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br mail: jarbas.peixoto(a)previdencia.gov.br cn: Jarbas Peixoto Junior pwdAccountLockedTime: 20091202161422Z pwdFailureTime: 20091202162324Z pwdFailureTime: 20091202162805Z pwdFailureTime: 20091202162925Z pwdFailureTime: 20091202164558Z pwdFailureTime: 20091202164702Z pwdFailureTime: 20091202165016Z pwdFailureTime: 20091202181310Z pwdFailureTime: 20091202182914Z pwdFailureTime: 20091202183248Z pwdFailureTime: 20091202190153Z pwdFailureTime: 20091202191147Z pwdFailureTime: 20091202191544Z pwdFailureTime: 20091202191644Z pwdFailureTime: 20091202192051Z modifyTimestamp: 20091202192133Z I tried to identify any problems that may be in the logs. I made the following: /etc/init.d/slapd stop Stopping OpenLDAP: slapd. > /var/log/debug /etc/init.d/slapd start Starting OpenLDAP: slapd. tail /var/log/debug -n 50 Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi807249521$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=douglas.dcosta,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813149827$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813149622$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808649957$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=apssc-fcn333$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808638963$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=mgapssba055$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808644351$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813148464$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813148430$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808643444$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=admin.udsl,ou=Servicos,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=admin.listas,ou=Servicos,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "cn=default,ou=ldappassword,ou=politicas,ou=builtin,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: <= acl_access_allowed: granted to database root Dec 2 18:01:59 squeeze slapd[21772]: conn=1000 op=0 RESULT tag=97 err=49 text= Dec 2 18:01:59 squeeze slapd[21772]: conn=1000 fd=15 closed (connection lost) grep 'access_allowed: search access to' /var/log/debug | wc -l 83714 The question is: why access all entries in LDAP? Does anyone have any tips, or it may be some as yet unidentified BUG? As tests, I installed the version 2.4.20 and had the same behavior. Best Regards, Jarbas

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 02 Dec '09

02 Dec '09

I have updated to 2.4.20 and this problem gone. So this ITS could be closed.

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I applied the diff from http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/bconfig.c.diff?r1=1.… to 2.4.20, rebuilt and retested, it works now. Thanks! - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksWY94ACgkQeEJZs/PdwpCkoACg4xdTEzYb1QuQhjUfjtLHxSBK 74IAoMnwcVdaHsIhaiwwm8fnbx0DDgx8 =jss8 -----END PGP SIGNATURE-----

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I also just uploaded a new attachment to the launchpad bug entry with the contents of the slapd.d/ directory. - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksVMTMACgkQeEJZs/PdwpAN5wCgru6E73Ex1kKdrSpwxCq6zbR9 vzcAmwczNIFgUK5w+8cz2gniT9g1NG8X =IZTr -----END PGP SIGNATURE-----

1 0

(ITS#6409) ldap_init_fd and LDAPS
by viatly.kroivets＠gmail.com 02 Dec '09

02 Dec '09

Full_Name: Vitaly Kroivets Version: 2.4.20 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.115.180.11) It seems that function ldap_init_fd can not be used in LDAPS connection . I tried LDAP over SSL (without start-tls), but maybe with start-tls will be same.. I copied here my program. Use it this way : a.out -H ldaps://{IP}:636 -i {your src IP} -D {user} -w {password} Thanks! ====== #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <ldap.h> char* url = NULL; char* host_uri = NULL; char* bind_dn = NULL; char* password = NULL; char* out_file = NULL; LDAP* server = NULL; LDAPURLDesc* ludp = NULL; char* attribute = NULL; char* dn = NULL; BerElement* ber = NULL; LDAPMessage* result; void OnExitHandler(); void PrintUsage(); char src_ip [64]; int main(int argc, char* argv[]) { atexit(OnExitHandler); char c; while ((c = getopt(argc, argv, "H:w:D:o:i:")) != EOF) { switch (c) { case 'H': { url = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(url, optarg); break; } case 'D': { bind_dn = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(bind_dn, optarg); break; } case 'w': { password = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(password, optarg); break; } case 'o': { out_file = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(out_file, optarg); break; } case 'i': { strncpy(src_ip, optarg, sizeof (src_ip)); break; } default: { PrintUsage(); return 1; break; } } } if (url == NULL || (bind_dn == NULL && password != NULL)) { PrintUsage(); return 1; } int rc = ldap_url_parse(url, &ludp); if (rc != 0) { fprintf(stderr, "ldap_url_parse: %s\n", ldap_err2string(rc)); return 1; } // server = ldap_init(ludp->lud_host, ludp->lud_port); // ldap_initialize is undocumented call we use instead of ldap_init // it allows to work over TLS secured connection, i.e. using ldaps:// int host_uri_len = strlen(ludp->lud_scheme) + strlen(ludp->lud_host) + 16; host_uri = (char*)malloc(sizeof(char) * host_uri_len); sprintf(host_uri, "%s://%s:%d", ludp->lud_scheme, ludp->lud_host, ludp-> lud_port); int sockfd ; printf ("%s;\n",ludp->lud_host); { // struct hostent *gethostbyname(const char *name); struct hostent *he; struct sockaddr_in their_addr; // connector's address information if ( (he=gethostbyname( ludp->lud_host )) == NULL ) { // get the host info herror("gethostbyname"); exit(1); } if ((sockfd = socket(PF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } their_addr.sin_family = AF_INET; their_addr.sin_port = htons(ludp-> lud_port); their_addr.sin_addr = *((struct in_addr *)he->h_addr); memset(their_addr.sin_zero, '\0', sizeof their_addr.sin_zero); // { struct sockaddr_in my_addr; // my address information my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = 0; // short, network byte order my_addr.sin_addr.s_addr = inet_addr(src_ip); memset(my_addr.sin_zero, '\0', sizeof my_addr.sin_zero); if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof my_addr) == -1) { perror("bind"); exit(1); } } // if (connect(sockfd, (struct sockaddr *)&their_addr, sizeof their_addr) == -1) { perror("connect"); exit(1); } //connect mysock... printf ("init=%d\n", ldap_init_fd (sockfd , 1 ,host_uri , &server)); } /* // rc = ldap_initialize(&server, host_uri); if (rc != 0) { fprintf(stderr, "ldap_initialize: %s", (*ldap_err2string)(rc)); return 1; } */ //server->ld_conns->lconn_server = 0;//ldap_url_dup ( ludp ); rc = ldap_simple_bind_s(server, bind_dn, password); if (rc != 0) { fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); return 1; } rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, ludp->lud_filter, ludp->lud_attrs, 0, &result); if (rc != 0 && rc != LDAP_SIZELIMIT_EXCEEDED) { fprintf(stderr, "ldap_search_s: %s\n", (*ldap_err2string)(rc)); return 1; } int num = ldap_count_entries(server, result); fprintf(stderr, "Number of messages: %d\n", ldap_count_messages(server, result)); if (num == 0) { fprintf(stderr, "ldap_count_entries: no entries received\n"); return 1; } else if (num > 1) { fprintf(stderr, "ldap_count_entries: more than one entry received\n"); return 1; } LDAPMessage* entryIterator = ldap_first_entry(server, result); dn = ldap_get_dn(server, entryIterator); attribute = ldap_first_attribute(server, entryIterator, &ber); if (attribute == NULL) { fprintf(stderr, "ldap_first_attribute: no attriubutes received\n"); return 1; } else if (ldap_next_attribute(server, entryIterator, ber)) { fprintf(stderr, "ldap_first_attribute: more than one attriubute received\n"); return 1; } else { BerValue** vals = ldap_get_values_len(server, entryIterator, attribute); num = ldap_count_values_len(vals); if (vals == NULL || num == 0) { fprintf(stderr, "ldap_count_values_len :no values received\n"); return 1; } else if (num > 1) { fprintf(stderr, "ldap_count_values_len :more than one value received\n"); return 1; } FILE* fo = NULL; if (out_file) { fo = fopen(out_file, "wb"); } else { fo = stdout; } fwrite(vals[0]->bv_val, 1, vals[0]->bv_len, fo); fflush(fo); fprintf(stderr, "Responce received from '%s'\n", url); if (out_file) fprintf(stderr, "Stored into %s\n", out_file); /* Free memory used to store values */ ldap_value_free_len(vals); } return 0; } void OnExitHandler() { if (result) { ldap_msgfree(result); } if (dn) ldap_memfree(dn); if (attribute) ldap_memfree(attribute); if (ber) ber_free(ber, 0); if (ludp) ldap_free_urldesc(ludp); if (server) ldap_unbind_s(server); if (url) free(url); if (host_uri) free(host_uri); if (bind_dn) free(bind_dn); if (password) free(password); if (out_file) free(out_file); } void PrintUsage() { fprintf(stderr, "Usage: ldapget -H <LDAP URI> [-o <output_file>] [-D user [-w password]] [-i src_ip_addr ] \n"); }

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Michael Ströder wrote: > Howard Chu wrote: >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> Howard Chu wrote: >>>>> michael(a)stroeder.com wrote: >>>>>> Download content of testrun/ here: >>>>>> >>>>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >>>>> >>>>> Shows that a change was replicated to the consumer and ignored on the >>>>> consumer. But since there's no SYNC logging enabled, we don't see the >>>>> reason why the consumer did this... >>>> >>>> It does not happen very often. This time I had to run it almost 50 >>>> times. >>>> >>>> Hope I got the sync log level right herein: >>>> >>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… >>>> >>> >>> I think you have an OS / clock problem. The skipped op in this case got >>> assigned an entryCSN older than the immediately preceding op. (The >>> missing op >>> has CSN 20091130201002.575384Z. The preceding op was >>> 20091130201002.577244Z) >>> This test doesn't run any concurrent operations, each new op is only >>> submitted >>> after the previous one completes, so this is not a thread concurrency >>> issue, >>> your system clock is going backwards. >>> >> A patch for this is now in libldap/util-int.c in HEAD. > > Hmm, this is a virtual machine running in vmware-player 64 bit. But I didn't > suspect to have a clock issue therein since the host is a rather fast > dual-core notebook. I will investigate this. The one thing you can rely on as far as clocks in VMware is that they will be wrong, regardless of your CPU speed. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di… -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Download content of testrun/ here: >>>> >>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >>> >>> Shows that a change was replicated to the consumer and ignored on the >>> consumer. But since there's no SYNC logging enabled, we don't see the >>> reason why the consumer did this... >> >> It does not happen very often. This time I had to run it almost 50 times. >> >> Hope I got the sync log level right herein: >> >> http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… > > I think you have an OS / clock problem. The skipped op in this case got > assigned an entryCSN older than the immediately preceding op. (The missing op > has CSN 20091130201002.575384Z. The preceding op was 20091130201002.577244Z) > This test doesn't run any concurrent operations, each new op is only submitted > after the previous one completes, so this is not a thread concurrency issue, > your system clock is going backwards. > A patch for this is now in libldap/util-int.c in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Howard Chu wrote: > Michael Ströder wrote: >> Hmm, this is a virtual machine running in vmware-player 64 bit. But I didn't >> suspect to have a clock issue therein since the host is a rather fast >> dual-core notebook. I will investigate this. > > The one thing you can rely on as far as clocks in VMware is that they will be > wrong, regardless of your CPU speed. > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di… > Read more... http://www.google.com/search?q=site%3Avmware.com+clock The "Timekeeping" PDF doc is a pretty good explanation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unfortunately ftp.openldap.org/incoming is full: lftp ftp.openldap.org:/incoming> put AndreasHasenack-091201.tar.bz2 put: Access failed: 553 AndreasHasenack-091201.tar.bz2.30: No space left on device. The same files can be fetched from https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/485026 instead. - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksVH2cACgkQeEJZs/PdwpCw3QCgvnfE2Ynmzb7wFWvsuH81HmjV XpUAoLzmgy/qBkz4h68J1KJUIv4egNUY =wwV9 -----END PGP SIGNATURE-----

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Download content of testrun/ here: >>> >>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >> >> Shows that a change was replicated to the consumer and ignored on the >> consumer. But since there's no SYNC logging enabled, we don't see the >> reason why the consumer did this... > > It does not happen very often. This time I had to run it almost 50 times. > > Hope I got the sync log level right herein: > > http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… I think you have an OS / clock problem. The skipped op in this case got assigned an entryCSN older than the immediately preceding op. (The missing op has CSN 20091130201002.575384Z. The preceding op was 20091130201002.577244Z) This test doesn't run any concurrent operations, each new op is only submitted after the previous one completes, so this is not a thread concurrency issue, your system clock is going backwards. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2009