openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6411) Possible bug in Overlay pPolicy
by hyc＠symas.com 03 Dec '09

03 Dec '09

jarbas.junior(a)gmail.com wrote: > 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 > > grep 'access_allowed: search access to' /var/log/debug | wc -l > 83714 > > The question is: why access all entries in LDAP? Don't know. This would have to be the result of a search operation, but there is no search code in ppolicy.c. Since ppolicy cannot be the culprit, we'll need to see the rest of your config to track down the issue. -- -- 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#6411) Possible bug in Overlay pPolicy
by quanah＠zimbra.com 03 Dec '09

03 Dec '09

--On Wednesday, December 02, 2009 8:25 PM +0000 jarbas.junior(a)gmail.com wrote: > 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) ppolicy doesn't execute searches. Please provide your entire slapd.conf, minus passwords. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

02 Dec '09

andreas(a)canonical.com wrote: > -----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. Thanks, a fix was committed to HEAD yesterday. -- -- 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

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs