openldap-bugs

openldap-bugs@openldap.org

1 participants
21513 discussions

Crashing database
by Carlos Parada 06 Jan '08

06 Jan '08

Hi all, (First of all, sorry for this "generic" thread) I'm using the openldap 2.3.34 version (I've already used previous ones). My usage is a bit different than the usual. I have a lot of write operations - tens per second - (adds, deletes) and also a lots of reads. I use to have very often a crash in my database. I'm using the bdb backend. Sometimes it is enough to restart my server to corrupt the database (at least to not be able to restart it). In other occasions, I corrupt my database using the slapcat command, which I know it is nor recommended, but it is also not disallowed by the application (and I think it was in previous versions). That buggy behavior should not be normal. I've already search and it seems it is a common problem using the bdb, many times reported. My question is: what is really happening? Am I configuring wrongly the server, DBD parameters, or anything else? Or there is a systematic bug not solved yet ? How to solve it? Another secondary issue is the recovery. Most of the times, I'm not able to recover my database either using db_recover or slapd_db_recover. Is there any trick for a more efficient recovery. Cumprimentos, Carlos Parada

2 3

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by ando＠sys-net.it 05 Jan '08

05 Jan '08

Jose, few preliminary comments: - you coded your contribution for OpenLDAP 2.3; however, since it configures as a new feature, it should be coded for OpenLDAP 2.4 (better for HEAD), as 2.3 is feature-frozen ever since. This comment may appear trivial, but right now your contribution does not compile with HEAD/re24 because of some internal API changes. - the coding style you used does not conform to that of the OpenLDAP project. Although this is usually only loosely enforced, you used things we're a bit picky about, like C++-style comments, and late declarations; if you compile with enough warnings (e.g., with gcc, with -Wall -pedantic) you'll see that in many cases functions are not returning when a return value is expected or vice-versa; incorrect formats are used for (long) integers, pointers and so. Also, I note that besides being a totally new contribution, many of the comments are already no longer aligned with the code. - according to agreed development lines, new contributions should always provide back-config support (this can be added later, if and when the rest works as expected) - with respect to the possible improvements you indicate, I think: 1) permission checking should occur along the lines of, e.g., slapo-dynlist(5), honoring dgIdentity and dgAuthz. 2) avoiding unnecessary expansion would probably be mandatory for production use 3) use back-config rather than naive in-database configuration using an ordinary database - The build instructions you provide are incorrect: you suggest to place the source in servers/slapd/overlays/, and to modify statover.c; this is a generated file, so it should never be modified. You should rather suggest to place the sources in an arbitrary directory (it could be contrib/slapd-modules/nestedAggregateAttr as soon as your contribution enters the official distribution) and build it as a run-time module. - you should rather eliminate duplicate values from result sets (much like slapo-dynlist(5) does) as they are not allowed by the definition of the "member" attribute, which has a distinguishedNameMatch EQUALITY rule. - instead of copying compare_entry(), you should rather ask to make the one in servers/slapd/compare.c non-static - since the "OR" operator in filters allows more than 2 operands, I think your filter combination strategy could be optimized by simply defining a combine_filters() function that counts the number of filter strings in the array and creates a filter like "(|(f1)(f2)(f3)...)" - in check_filter(), you compare strings; you should rather compare pointers to AttributeDescription structures. - in nestedAggregateAttrURL_search() you don't need to run str2filter() on op->ors_filterstr, since an exploded filter is already available in op->ors_filter - strings[] containing "(objectClass=<ocname>)" could be prepared once for all during config; it would save a lot of mallocs (BTW: use the slab for operation-spanning allocation). - I would recommend you do some consistent checking of return values before dereferencing pointers. - I would recommend that you either remove or turn into useful standard debugging the plethora of non-standard messages you added. Use LDAP_DEBUG_ARGS to mark entering/exiting functions (and logging useful args); use LDAP_DEBUG_TRACE to trace operations; use slap_loglevel_get() to register friendly names for specific log subsystems (you'll get back the number to compare with ldap_debug). - with respect to the OID for the test schema items, you'll get an OID arc in the experimental OID namespace of the OpenLDAP project as soon as your contribution is incorporated. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by ando＠sys-net.it 05 Jan '08

05 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Yes, you are completely right. The only reason I can think of using the > DN version is because you are forced by your schema (attribute types for the > expansion source attribute differ). I emphasize that the implementation of > both is quite different. The DN version uses recursivity while the URL > version relies in slapd's search-reply mechanism. I just added the first one > as an example. > > URL version is much more powerful and more elegant. You suggested > subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok > (if I remember right). According to Section 3 of RFC 4516, if <scope> is omitted, a scope of "base" is assumed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

RE: (ITS#5307) www.openldap.org doesn't respond to Ipv6 requests
by matt＠windu.com 04 Jan '08

04 Jan '08

Sweet, thanks guys for running IPv6. Have a good weekend. -Matt > -----Original Message----- > From: Kurt Zeilenga [mailto:kurt@OpenLDAP.org] > Sent: Friday, January 04, 2008 2:51 PM > To: openldap-its(a)OpenLDAP.org > Cc: matt(a)windu.com > Subject: Re: (ITS#5307) www.openldap.org doesn't respond to Ipv6 > requests > > Try again... (restarted listener).

1 0

Re: (ITS#5307) www.openldap.org doesn't respond to Ipv6 requests
by kurt＠OpenLDAP.org 04 Jan '08

04 Jan '08

Try again... (restarted listener).

1 0

(ITS#5307) www.openldap.org doesn't respond to Ipv6 requests
by matt＠windu.com 04 Jan '08

04 Jan '08

Full_Name: Matt Bradbury Version: n/a OS: n/a URL: Submission from: (NULL) (198.252.182.170) www.openldap.org has a ipv6 dns record, unfortunately the server does not respond on that address. Luckily, or is that unluckily, I can still access your page via Internet Explorer which falls back to IPv4 if the server doesn't respond. I'm running Opera, which doesn't fall back to Ipv4 addresses. While this may not affect many customers, it would be nice to have the native support on the server or remove the entry from DNS if it's not actually responding to the IPv6 address. Thank you for your time. -Matt ps. Here's a couple of command prompt captures of my testing C:\Users\bradbury>ping www.openldap.org Pinging www.openldap.org [2001:4f8:3:ba:2e0:18ff:fe02:efec] from 2610:160:0:1008 :999e:9cad:c29d:5d16 with 32 bytes of data: Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=58ms Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=60ms Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=59ms Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=62ms Ping statistics for 2001:4f8:3:ba:2e0:18ff:fe02:efec: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 58ms, Maximum = 62ms, Average = 59ms C:\Users\bradbury>telnet 2001:4f8:3:ba:2e0:18ff:fe02:efec 80 Connecting To 2001:4f8:3:ba:2e0:18ff:fe02:efec...Could not open connection to th e host, on port 80: Connect failed C:\Users\bradbury>

1 0

Re: (ITS#5306) install ladp
by ando＠sys-net.it 04 Jan '08

04 Jan '08

aslang(a)ntu.edu.sg wrote: > I keep having this error: please advice > > slapadd -l init.ldif > /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. > /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. > str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and > "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" > slapadd: could not parse entry (line=52) > > In my init.ldif, I do have line 52, my last line is 51 > This is the content of my init.ldif file > > dn: dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: dcObject > objectClass: organizationalUnit > dc: 4g > ou: NTU 4G Lab > dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: people > dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: staff > dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: students > dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: visitors > dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: shadowAccount > uid: linda > sn: Ang > givenName: Linda > cn: Linda Ang > displayName: Linda Ang > uidNumber: 1000 > gidNumber: 10000 > userPassword: password > gecos: Linda Ang > loginShell: /bin/bash > homeDirectory: /home/linda > shadowExpire: -1 > shadowFlag: 0 > shadowWarning: 7 > shadowMin: 8 > shadowMax: 999999 > shadowLastChange: 10877 > mail: linda_yong(a)hotmail.com > postalCode: 31000 > l: Toulouse > o: Example > mobile: +65 (0)6 12345678 > homePhone: +33 (0)5 12345678 > title: System Administrator > postalAddress: > initials: LA > dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg > objectClass: posixGroup > cn: 4g > gidNumber: 10000 The error you see represents the expected behavior, since your LDIF file is invalid; please check your syntax. As there appears to be no OpenLDAP software bug, this ITS will be closed. Please direct further discussion to OpenLDAP-software. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by josemarcodelarosa＠gmail.com 04 Jan '08

04 Jan '08

------=_Part_27665_28430263.1199452056921 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, you are completely right. The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example. URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right). ------=_Part_27665_28430263.1199452056921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline   Yes, you are completely right.  The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example.   URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right). ------=_Part_27665_28430263.1199452056921--

1 0

(ITS#5306) install ladp
by aslang＠ntu.edu.sg 03 Jan '08

03 Jan '08

Full_Name: Linda Ang Version: OpenLDAP: slapd 2.3.35 OS: Ububtu 1.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.69.2.5) I keep having this error: please advice slapadd -l init.ldif /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" slapadd: could not parse entry (line=52) In my init.ldif, I do have line 52, my last line is 51 This is the content of the /etc/ldap/slapd.conf file ######################### /etc/ldap/slapd.conf ######################### # http://homex.subnet.at/~max/ldap/ # # Basic slapd.conf # # 2005.02.08 ZHANG.Guiyu(a)example.com ######################################################################## # Global Directives: # # Features to permit #allow bind_v2 # Schema and objectClass definitions # not all required, if you get errors about missing schema, comment out the missing schema here # some are provided by other packages such as samba include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/samba.schema # Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb #moduleload back_passwd ####################################################################### # Specific Backend Directives for ldbm: # Backend specific directives apply to this backend until another # backend' directive occurs backend bdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs # backend <other> ####################################################################### # Specific Directives for database #1, of type ldbm: # Database specific directives apply to this databasse until another # 'database' directive occurs # # important: use bdb format, other formats like ldbm can cause data corruption database bdb # The base of your directory in database #1 suffix "dc=4g,dc=ntu,dc=edu,dc=sg" rootdn "cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" password-hash {CRYPT} #rootpw {CRYPT}asdfghjkl # # use "/usr/sbin/slappasswd -h {CRYPT}" to create a rootpw-string below rootpw {CRYPT}1zLLT3DU571FM # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only # access to attrs=userPassword,sambaLMPassword,sambaNTPassword by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by anonymous auth by self write by * none access to * by dn="cn=nss,dc=ntu,dc=edu,dc=sg" read by * auth # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. #access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=admin,dc=mail,dc=example,dc=com" write # by dnattr=owner write ####################################################################### # Specific Directives for database #2, of type 'other' (can be bdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # #The base of your directory for database #2 #suffix "dc=debian,dc=org" ####################################################################### This is the content of my init.ldif file dn: dc=4g,dc=ntu,dc=edu,dc=sg objectClass: dcObject objectClass: organizationalUnit dc: 4g ou: NTU 4G Lab dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: people dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: staff dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: students dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: visitors dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: linda sn: Ang givenName: Linda cn: Linda Ang displayName: Linda Ang uidNumber: 1000 gidNumber: 10000 userPassword: password gecos: Linda Ang loginShell: /bin/bash homeDirectory: /home/linda shadowExpire: -1 shadowFlag: 0 shadowWarning: 7 shadowMin: 8 shadowMax: 999999 shadowLastChange: 10877 mail: linda_yong(a)hotmail.com postalCode: 31000 l: Toulouse o: Example mobile: +65 (0)6 12345678 homePhone: +33 (0)5 12345678 title: System Administrator postalAddress: initials: LA dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg objectClass: posixGroup cn: 4g gidNumber: 10000

1 0

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by hyc＠symas.com 03 Jan '08

03 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Full_Name: Jose Marco de la Rosa > Version: 2.3.39 > OS: Kubuntu 7.10 > URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-0… > Submission from: (NULL) (80.25.122.131) > > > Two overlays that implement dynamic group classes defined with URL attributes > and allowing nesting. > > - The first one is an extension of th overlay expandURL but allowing nesting > > - The second one changes the way groups are constructed in a more powerful way > * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. > * if both are active, some searches don't behave as expacted! > * Specifically, if you turn both overlays on and search for > * 'entries with member=<some member value>' won't work properly > * for one of the overlays (the firstly activated one) Seems there's really no need for the nestedAggregateAttrDN overlay, since that is just a proper subset of a URL. I.e., anywhere you would use a simple DN is just a case of subGroupURL: ldap:///<dn>??base -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs