openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 22 Apr '10

22 Apr '10

Kurt Zeilenga wrote: > obsoletes != OBSOLETE, so no. That is, the meaning of the term > 'obsolete' is quite different in these two contexts. > > The latter context the term is defined as follows: The OBSOLETE field, if > present, indicates the element is not active. I agree that OBSOLETE should not be set in this case. > For user application attribute types, whether the type is active or not is, > I think, best left to the schema administrator. Who is the schema administrator? I'm nitpicking here because on the OpenLDAP lists we all keep telling OpenLDAP admins not to mess with the standard schema at all. IMO this includes setting OBSOLETE. Ciao, Michael.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by kurt＠OpenLDAP.org 21 Apr '10

21 Apr '10

On Apr 21, 2010, at 6:03 PM, masarati(a)aero.polimi.it wrote: >> Kurt Zeilenga wrote: >>>=20 >>> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>>> Updated schema file cosine-update.schema attached. >>>=20 >>> I note that differs are generally preferred, even where the file is >>> mostly changed. This helps ensure changes that others might make to = the >>> file you started with are not lost. >>=20 >> I thought about sending a diff but the file in this form is more >> readable for easy review. Could someone please look at it whether = that's >> ok? >=20 >> Another approach would be to have two schema files, one which only >> contains the schema descriptions from RFC 4524 and one with the = missing >> schema descriptions from RFC 1274 with the latter obviously being >> dependent on the former. >=20 > I have one preliminary question for Kurt: since rfc4524 obsoletes = rfc1274, > should those schema items that were not brought forward be marked as > OBSOLETE? obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term = 'obsolete' is quite different in these two contexts. The latter context the term is defined as follows: The OBSOLETE field, if present, indicates the element is not active. For user application attribute types, whether the type is active or not = is, I think, best left to the schema administrator. (Update operations = upon an inactive element is limited to removal of the element.) > If yes, then all schema could fit in one file. I'd like a > clear way to separate valid from obsolete schema. The obsolete items > should be available for backwards compatibility. As an alternative, = I'd > like to have a "slim" (without obsolete) and a complete version of the > file. I rather no element be specified in multiple files. > Could you please upload the file? Through the ITS attachments > don't work too well. >=20 >>>> IPR notice: >>>> This patch file is derived from OpenLDAP Software and RFC 4524 and = RFC >>>> 1274. All of the modifications to OpenLDAP Software represented in = the >>>> attached file were developed by Michael Str=F6der = <michael(a)stroeder.com>. >>>> I have not assigned rights and/or interest in this work to any = party. >>>=20 >>> While this notice of origin is fine, you did not include a rights >>> statement. >>=20 >> I, Michael Str=F6der, hereby place the modified schema file = cosine.schema >> attached to ITS#6151 (and only these modifications) into the public >> domain. Hence, these modifications may be freely used and/or >> redistributed for any purpose with or without attribution and/or = other >> notice. >=20 > Am I right in assuming this IPR is fine? Thanks, p. Yes. - Kurt

1 0

ITS#6250
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

Why is this ITS in software development, and open? Anyone intends to develop that feature, despite the discussion? p.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Kurt Zeilenga wrote: >> >> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>> Updated schema file cosine-update.schema attached. >> >> I note that differs are generally preferred, even where the file is >> mostly changed. This helps ensure changes that others might make to the >> file you started with are not lost. > > I thought about sending a diff but the file in this form is more > readable for easy review. Could someone please look at it whether that's > ok? > Another approach would be to have two schema files, one which only > contains the schema descriptions from RFC 4524 and one with the missing > schema descriptions from RFC 1274 with the latter obviously being > dependent on the former. I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274, should those schema items that were not brought forward be marked as OBSOLETE? If yes, then all schema could fit in one file. I'd like a clear way to separate valid from obsolete schema. The obsolete items should be available for backwards compatibility. As an alternative, I'd like to have a "slim" (without obsolete) and a complete version of the file. Could you please upload the file? Through the ITS attachments don't work too well. >>> IPR notice: >>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >>> 1274. All of the modifications to OpenLDAP Software represented in the >>> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >>> I have not assigned rights and/or interest in this work to any party. >> >> While this notice of origin is fine, you did not include a rights >> statement. > > I, Michael Ströder, hereby place the modified schema file cosine.schema > attached to ITS#6151 (and only these modifications) into the public > domain. Hence, these modifications may be freely used and/or > redistributed for any purpose with or without attribution and/or other > notice. Am I right in assuming this IPR is fine? Thanks, p.

1 0

Re: (ITS#6529) slapcat: bad configuration file!
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Full_Name: SLava > Version: 2.4.21 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.120.255.22) > > > My aim is to regularly backup openldap database, so I created a special > backup-user to do that. But while doing this command: "slapcat -f > /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I > get this > error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied > slapcat: bad configuration file!". I watched my conf file and there is > "directory /var/lib/openldap-data/my-domain-com" string in line 77. I > looked for > permission rights and all seems to be properly. Don't know what to do... > > By the way, the same command under "root" works perfectly. Your file permissions are obviously inappropriate for the operation you're trying to perform. There is no evidence of an OpenLDAP bug; there is not even an evidence of an LDAP-related issue. This ITS will be closed. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

This is a known issue. That patch is now obsoleted by the code that has been committed to HEAD and ported to re24 for release. Please test re24 out of the CVS, or apply the corresponding modifications to slapd/syncrepl.c to 2.4.21, and test. Please note that test018 has been modified to reproduce and test the problem you highlighted. If you run the new test18 with 2.4.21 it should consistently fail, while it passes with the new code. p. > Hello, > > Le 17/04/2010 22:00, > masarati(a)aero.polimi.it (par Internet) a écrit : >> A fix is in HEAD, please test > > I have tried the compilaltion of the source 2.4.21 with your patch, > "make test" failed on "test020-proxycache for bdb" with this error : > > >>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > ./scripts/test020-proxycache: line 173: 16714 Erreur de segmentation > $SLAPD -f $CONF2 -h $URI2 -d $LVL -d pcache > $LOG2 2>&1 > ldapsearch failed (255)! > ./scripts/test020-proxycache: line 177: kill: (16714) - Aucun processus > de ce type > >>>>> ./scripts/test020-proxycache failed for bdb (exit 255) > make[2]: *** [bdb-mod] Erreur 255 > make[2]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make[1]: *** [test] Erreur 2 > make[1]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make: *** [test] Erreur 2 > > I have used this compilation steps : > tar -zxvf openldap-2.4.21.tgz > > cd openldap-2.4.21 > > patch -p0 < ../pierangelo-masarati-2010-04-17-sync-rename.1.patch > patching file servers/slapd/syncrepl.c > Hunk #2 succeeded at 2554 (offset -10 lines). > Hunk #3 succeeded at 2891 (offset -10 lines). > Hunk #4 succeeded at 3026 (offset -10 lines). > > ./configure --enable-debug --enable-dynamic --enable-syslog > --enable-proctitle --enable-ipv6 --enable-local --enable-slapd > --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd > --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups > --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod > --enable-ldbm=no --disable-ndb --enable-overlays=mod --with-subdir=ldap > --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc > > make depend > > make > > make test > > regards, > Julien > >

1 0

(ITS#6529) slapcat: bad configuration file!
by slava.kargaltsev＠gmail.com 21 Apr '10

21 Apr '10

Full_Name: SLava Version: 2.4.21 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.120.255.22) My aim is to regularly backup openldap database, so I created a special backup-user to do that. But while doing this command: "slapcat -f /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I get this error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied slapcat: bad configuration file!". I watched my conf file and there is "directory /var/lib/openldap-data/my-domain-com" string in line 77. I looked for permission rights and all seems to be properly. Don't know what to do... By the way, the same command under "root" works perfectly.

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> Can you give me the exact commands I need to put into the wiki, for a > user to go from a checkout of OpenLDAP, to a build with this module > installed just like all the others? Assuming one builds in the tree, - follow instructions for anonymous CVS checkout of HEAD branch <http://www.openldap.org/software/repo.html#AnonCVS> - cd contrib/slapd-modules/samba4 - edit Makefile if needed; as it is, it assumes you build in tree, and installs in /usr/local/libexec/openldap - make; make install - in slapd.conf: modulepath /usr/local/libexec/openldap moduleload rdnval.la # ... database hdb # ... overlay rdnval That's it. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-GJES2Ff4FHn/Nl+ftOBF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 05:42 +0200, masarati(a)aero.polimi.it wrote: > > My eventual goal is that folks using a Ubuntu or Fedora system would > > have Samba4 'just work' with the packaged OpenLDAP. I can of course > > lobby them to get their packages updated to build from contrib, but it'= s > > easier if it's just in there.=3D20 > > > > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the > > short term, it is of course easier for me if everything is already in > > place.=3D20 > > > > But this is your project, not mine, and I am happy with whatever we can > > make work.=3D20 >=20 > Right now, along the lines illustrated by Howard, I've committed > everything to contrib/slapd-modules/samba4. You may need to tweak the > Makefile if you are not building in the source tree (as I usually do; the= n > adjust LDAP_BUILD to your build tree), and if you wish to install modules > in some specific place (prefix, exec_prefix, ldap_subdir). >=20 > My medium term objective would be to have: >=20 > - generally useful modules built-in (e.g. slapo-deref) >=20 > - Samba4-specific modules all in one contrib directory, possibly > harmonized and consolidated when possible in a single module, to ease > configuration and maintenance >=20 > The latter could then have a specific configure, if needed, so that > packagers could make and install them as easily as possible. In the > meanwhile, we should live with this interim solution. Time permitting, I > see no issue in maintaining that code, much like we already do with the > other modules. Can you give me the exact commands I need to put into the wiki, for a user to go from a checkout of OpenLDAP, to a build with this module installed just like all the others? Thanks, --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-GJES2Ff4FHn/Nl+ftOBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLznxIz4A8Wyi0NrsRAl6mAJ4+rykBiTBAhn3ANiDgEfc8dG1OAgCghGeg ycx5bF3Vlb1Yx3OMwa3p13k= =XUh6 -----END PGP SIGNATURE----- --=-GJES2Ff4FHn/Nl+ftOBF--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> My eventual goal is that folks using a Ubuntu or Fedora system would > have Samba4 'just work' with the packaged OpenLDAP. I can of course > lobby them to get their packages updated to build from contrib, but it's > easier if it's just in there.=20 > > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the > short term, it is of course easier for me if everything is already in > place.=20 > > But this is your project, not mine, and I am happy with whatever we can > make work.=20 Right now, along the lines illustrated by Howard, I've committed everything to contrib/slapd-modules/samba4. You may need to tweak the Makefile if you are not building in the source tree (as I usually do; then adjust LDAP_BUILD to your build tree), and if you wish to install modules in some specific place (prefix, exec_prefix, ldap_subdir). My medium term objective would be to have: - generally useful modules built-in (e.g. slapo-deref) - Samba4-specific modules all in one contrib directory, possibly harmonized and consolidated when possible in a single module, to ease configuration and maintenance The latter could then have a specific configure, if needed, so that packagers could make and install them as easily as possible. In the meanwhile, we should live with this interim solution. Time permitting, I see no issue in maintaining that code, much like we already do with the other modules. p.

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