From daelic at gmail.com Mon Oct 1 18:46:45 2007 From: daelic at gmail.com (Jason) Date: Mon, 1 Oct 2007 11:46:45 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build Message-ID: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> Hello, I originally posted this on the users list, but was kindly directed to post here for hopefully better results. I'll paste the original mail below, but as an addendum, it's been pointed out that gmake is attempting to use gcc, rather than the sunworkshop compiler. I've no clue why, or even if that's part of why I'm getting this problem, but I figured I would get that out of the way up front. :) Here is my PATH: mrfreeze:/root/ldap/mozilla/directory/c-sdk>echo $PATH /opt/SUNWspro/bin:/usr/ccs/bin/:/usr/local/apache2/bin:/usr/ccs/bin/:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/proc/bin:/usr/local/bin:/usr/local/sbin:/usr/openwin/bin:/usr/ucb:/usr/platform/sun4u/sbin:/usr/lib:/root/scripts:/usr/ccs/bin/:/usr/local/apache2/ant/bin:/opt/OV/bin As you can see, /opt/SUNWspro/bin is at the top of my path, so I've no clue why it's trying to use gcc instead. now, here is the original email sent to users that describes the problem I'm seeing: hello, I'm trying to compile FDS 1.0.4 on a 280R running Solaris 8. After getting all of the prerequisites installed (gnu make, apr, ant, sun workshop compiler, etc) I started following the directions located here: http://www.directory.fedora.redhat.com/wiki/Building#External_Requirements I created my ldap directory, and downloaded the mozilla components tarball linked. I successfully compiled NSS via 'gmake nss_build all' I successfully compiled SVRCORE Next, I attempted to compile LDAPSDK (mozilla/directory/c-sdk) but I get a File not found error when it tries to link libatomic.o. About the only thing I've been able to learn from a few hours of google is that it appears that libatomic.o should come from NSPR, which, in theory, was compiled during the gmake nss_build_all according to the build documentation. Unfortunately, I cannot find libatomic.o anywhere on the system. Is there a way to get past this problem? Am I crazy for expecting this to compile on solaris even though solaris support is listed? Is there a better build guide I should be following? I've copied the compile errors below, in case it helps anyone see what's going on. Any help that can be provided is greatly appreciated! ~Jason ======= making ./libldap60.so gcc -shared -Wl,-soname -Wl, libldap60.so -f libatomic.so -o libldap60.so ./abandon.o ./add.o ./bind.o ./cache.o ./charray.o ./charset.o ./compare.o ./compat.o ./control.o ./countvalues.o ./delete.o ./disptmpl.o ./dsparse.o ./error.o ./extendop.o ./free.o ./freevalues.o ./friendly.o ./getattr.o ./getdn.o ./getdxbyname.o ./getentry.o ./getfilter.o ./getoption.o ./getvalues.o ./memcache.o ./message.o ./modify.o ./open.o ./os- ip.o ./proxyauthctrl.o ./psearch.o ./pwmodext.o ./referral.o ./regex.o ./rename.o ./request.o ./reslist.o ./result.o ./saslbind.o ./sbind.o ./search.o ./setoption.o ./sort.o ./sortctrl.o ./srchpref.o ./tmplout.o ./ufn.o ./unbind.o ./unescape.o ./url.o ./utf8.o ./vlistctrl.o ./saslio.o -L../../../../../dist/lib -llber60 gcc: libatomic.so: No such file or directory gmake[3]: *** [libldap60.so] Error 1 gmake[3]: Leaving directory `/root/ldap/mozilla/directory/c-sdk/ldap/libraries/libldap' gmake[2]: *** [export] Error 2 From rmeggins at redhat.com Mon Oct 1 18:50:18 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 01 Oct 2007 12:50:18 -0600 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> Message-ID: <4701416A.8050304@redhat.com> Jason wrote: > Hello, > > I originally posted this on the users list, but was kindly directed to > post here for hopefully better results. I'll paste the original mail > below, but as an addendum, it's been pointed out that gmake is > attempting to use gcc, rather than the sunworkshop compiler. I've no > clue why, or even if that's part of why I'm getting this problem, but > I figured I would get that out of the way up front. :) > > Here is my PATH: > > mrfreeze:/root/ldap/mozilla/directory/c-sdk>echo $PATH > /opt/SUNWspro/bin:/usr/ccs/bin/:/usr/local/apache2/bin:/usr/ccs/bin/:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/proc/bin:/usr/local/bin:/usr/local/sbin:/usr/openwin/bin:/usr/ucb:/usr/platform/sun4u/sbin:/usr/lib:/root/scripts:/usr/ccs/bin/:/usr/local/apache2/ant/bin:/opt/OV/bin > > As you can see, /opt/SUNWspro/bin is at the top of my path, so I've no > clue why it's trying to use gcc instead. > I'm not sure. mozldap uses configure but ignores many of the common variables such as CC. Can you try changing your PATH so that gcc is not found? > now, here is the original email sent to users that describes the > problem I'm seeing: > > hello, > > I'm trying to compile FDS 1.0.4 on a 280R running Solaris 8. After > getting all of the prerequisites installed (gnu make, apr, ant, sun > workshop compiler, etc) I started following the directions located > here: > > http://www.directory.fedora.redhat.com/wiki/Building#External_Requirements > > I created my ldap directory, and downloaded the mozilla components > tarball linked. > I successfully compiled NSS via 'gmake nss_build all' > I successfully compiled SVRCORE > > Next, I attempted to compile LDAPSDK (mozilla/directory/c-sdk) but I > get a File not found error when it tries to link libatomic.o. > > About the only thing I've been able to learn from a few hours of > google is that it appears that libatomic.o should come from NSPR, > which, in theory, was compiled during the gmake nss_build_all > according to the build documentation. Unfortunately, I cannot find > libatomic.o anywhere on the system. > > Is there a way to get past this problem? Am I crazy for expecting this > to compile on solaris even though solaris support is listed? Is there > a better build guide I should be following? > > I've copied the compile errors below, in case it helps anyone see > what's going on. Any help that can be provided is greatly appreciated! > > ~Jason > > ======= making ./libldap60.so > gcc -shared -Wl,-soname -Wl, libldap60.so -f libatomic.so -o > libldap60.so ./abandon.o ./add.o ./bind.o ./cache.o ./charray.o > ./charset.o ./compare.o ./compat.o ./control.o ./countvalues.o > ./delete.o ./disptmpl.o ./dsparse.o ./error.o ./extendop.o ./free.o > ./freevalues.o ./friendly.o ./getattr.o ./getdn.o ./getdxbyname.o > ./getentry.o ./getfilter.o ./getoption.o ./getvalues.o ./memcache.o > ./message.o ./modify.o ./open.o ./os- ip.o ./proxyauthctrl.o > ./psearch.o ./pwmodext.o ./referral.o ./regex.o ./rename.o ./request.o > ./reslist.o ./result.o ./saslbind.o ./sbind.o ./search.o ./setoption.o > ./sort.o ./sortctrl.o ./srchpref.o ./tmplout.o ./ufn.o ./unbind.o > ./unescape.o ./url.o ./utf8.o ./vlistctrl.o ./saslio.o > -L../../../../../dist/lib -llber60 > gcc: libatomic.so: No such file or directory > gmake[3]: *** [libldap60.so] Error 1 > gmake[3]: Leaving directory > `/root/ldap/mozilla/directory/c-sdk/ldap/libraries/libldap' > gmake[2]: *** [export] Error 2 > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 1 21:23:10 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Oct 2007 17:23:10 -0400 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> Message-ID: <4701653E.40406@redhat.com> Jason wrote: > Hello, > > I originally posted this on the users list, but was kindly directed to > post here for hopefully better results. I'll paste the original mail > below, but as an addendum, it's been pointed out that gmake is > attempting to use gcc, rather than the sunworkshop compiler. I've no > clue why, or even if that's part of why I'm getting this problem, but > I figured I would get that out of the way up front. :) > > Here is my PATH: > > mrfreeze:/root/ldap/mozilla/directory/c-sdk>echo $PATH > /opt/SUNWspro/bin:/usr/ccs/bin/:/usr/local/apache2/bin:/usr/ccs/bin/:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/proc/bin:/usr/local/bin:/usr/local/sbin:/usr/openwin/bin:/usr/ucb:/usr/platform/sun4u/sbin:/usr/lib:/root/scripts:/usr/ccs/bin/:/usr/local/apache2/ant/bin:/opt/OV/bin > > As you can see, /opt/SUNWspro/bin is at the top of my path, so I've no > clue why it's trying to use gcc instead. > > now, here is the original email sent to users that describes the > problem I'm seeing: > > hello, > > I'm trying to compile FDS 1.0.4 on a 280R running Solaris 8. After > getting all of the prerequisites installed (gnu make, apr, ant, sun > workshop compiler, etc) I started following the directions located > here: > > http://www.directory.fedora.redhat.com/wiki/Building#External_Requirements > > I created my ldap directory, and downloaded the mozilla components > tarball linked. > I successfully compiled NSS via 'gmake nss_build all' > I successfully compiled SVRCORE > > Next, I attempted to compile LDAPSDK (mozilla/directory/c-sdk) but I > get a File not found error when it tries to link libatomic.o. > > About the only thing I've been able to learn from a few hours of > google is that it appears that libatomic.o should come from NSPR, > which, in theory, was compiled during the gmake nss_build_all > according to the build documentation. Unfortunately, I cannot find > libatomic.o anywhere on the system. > > Is there a way to get past this problem? Am I crazy for expecting this > to compile on solaris even though solaris support is listed? Is there > a better build guide I should be following? > > I've copied the compile errors below, in case it helps anyone see > what's going on. Any help that can be provided is greatly appreciated! > > ~Jason > > ======= making ./libldap60.so > gcc -shared -Wl,-soname -Wl, libldap60.so -f libatomic.so -o > libldap60.so ./abandon.o ./add.o ./bind.o ./cache.o ./charray.o > ./charset.o ./compare.o ./compat.o ./control.o ./countvalues.o > ./delete.o ./disptmpl.o ./dsparse.o ./error.o ./extendop.o ./free.o > ./freevalues.o ./friendly.o ./getattr.o ./getdn.o ./getdxbyname.o > ./getentry.o ./getfilter.o ./getoption.o ./getvalues.o ./memcache.o > ./message.o ./modify.o ./open.o ./os- ip.o ./proxyauthctrl.o > ./psearch.o ./pwmodext.o ./referral.o ./regex.o ./rename.o ./request.o > ./reslist.o ./result.o ./saslbind.o ./sbind.o ./search.o ./setoption.o > ./sort.o ./sortctrl.o ./srchpref.o ./tmplout.o ./ufn.o ./unbind.o > ./unescape.o ./url.o ./utf8.o ./vlistctrl.o ./saslio.o > -L../../../../../dist/lib -llber60 > gcc: libatomic.so: No such file or directory > gmake[3]: *** [libldap60.so] Error 1 > gmake[3]: Leaving directory > `/root/ldap/mozilla/directory/c-sdk/ldap/libraries/libldap' > gmake[2]: *** [export] Error 2 Well, it gets added in directory/c-sdk/config/SunOS5.mk I don't know what the impact of removing it would be. Based on the comments of those files it is just an assembly language version for Ultrasparcs, so perhaps none. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From daelic at gmail.com Mon Oct 1 23:24:12 2007 From: daelic at gmail.com (Jason) Date: Mon, 1 Oct 2007 16:24:12 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <4701416A.8050304@redhat.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> Message-ID: <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> On 10/1/07, Richard Megginson wrote: > I'm not sure. mozldap uses configure but ignores many of the common > variables such as CC. Can you try changing your PATH so that gcc is not > found? Thanks, that forced the correct compiler, and it seems to have gotten past the original issue, but now I'm getting a different error: cc -xstrconst -o bin/ldapdelete ldapdelete.o common.o convutf8.o fileurl.o ldaptool-sasl.o argpin.o ntuserpin.o -L../../../../../dist/./lib -lssldap60 -lprldap60 -lldap60 -lldif60 -L../../../../../dist/lib -L/root/ldap/mozilla/dist/SunOS5.8_OPT.OBJ/lib -lsvrcore -L/root/ldap/mozilla/dist/SunOS5.8_OPT.OBJ/lib -lssl3 -lnss3 -lsoftokn3 -L/root/ldap/mozilla/dist/SunOS5.8_OPT.OBJ/lib -lplc4 -lplds4 -lnspr4 -lthread -lposix4 -lsocket -lnls -ldl -lresolv -lgen Undefined first referenced symbol in file sasl_errdetail ../../../../../dist/./lib/libldap60.so sasl_client_new ../../../../../dist/./lib/libldap60.so sasl_set_alloc ../../../../../dist/./lib/libldap60.so sasl_decode ../../../../../dist/./lib/libldap60.so sasl_encode ../../../../../dist/./lib/libldap60.so sasl_client_step ../../../../../dist/./lib/libldap60.so sasl_client_init ../../../../../dist/./lib/libldap60.so sasl_getprop ../../../../../dist/./lib/libldap60.so sasl_client_start ../../../../../dist/./lib/libldap60.so sasl_setprop ../../../../../dist/./lib/libldap60.so sasl_dispose ../../../../../dist/./lib/libldap60.so ld: fatal: Symbol referencing errors. No output written to bin/ldapdelete gmake[2]: *** [bin/ldapdelete] Error 1 gmake[2]: Leaving directory `/root/ldap/mozilla/directory/c-sdk/ldap/clients/tools' gmake[1]: *** [export] Error 2 gmake[1]: Leaving directory `/root/ldap/mozilla/directory/c-sdk/ldap' gmake: *** [export] Error 2 Any ideas? From rmeggins at redhat.com Tue Oct 2 00:06:26 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 01 Oct 2007 18:06:26 -0600 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> Message-ID: <47018B82.70308@redhat.com> Jason wrote: > On 10/1/07, Richard Megginson wrote: > > >> I'm not sure. mozldap uses configure but ignores many of the common >> variables such as CC. Can you try changing your PATH so that gcc is not >> found? >> > > > Thanks, that forced the correct compiler, and it seems to have gotten > past the original issue, but now I'm getting a different error: > > cc -xstrconst -o bin/ldapdelete ldapdelete.o common.o convutf8.o > fileurl.o ldaptool-sasl.o argpin.o ntuserpin.o > -L../../../../../dist/./lib -lssldap60 -lprldap60 -lldap60 -lldif60 > -L../../../../../dist/lib > -L/root/ldap/mozilla/dist/SunOS5.8_OPT.OBJ/lib -lsvrcore > -L/root/ldap/mozilla/dist/SunOS5.8_OPT.OBJ/lib -lssl3 -lnss3 > -lsoftokn3 -L/root/ldap/mozilla/dist/SunOS5.8_OPT.OBJ/lib -lplc4 > -lplds4 -lnspr4 -lthread -lposix4 -lsocket -lnls -ldl -lresolv -lgen > Undefined first referenced > symbol in file > sasl_errdetail ../../../../../dist/./lib/libldap60.so > sasl_client_new ../../../../../dist/./lib/libldap60.so > sasl_set_alloc ../../../../../dist/./lib/libldap60.so > sasl_decode ../../../../../dist/./lib/libldap60.so > sasl_encode ../../../../../dist/./lib/libldap60.so > sasl_client_step ../../../../../dist/./lib/libldap60.so > sasl_client_init ../../../../../dist/./lib/libldap60.so > sasl_getprop ../../../../../dist/./lib/libldap60.so > sasl_client_start ../../../../../dist/./lib/libldap60.so > sasl_setprop ../../../../../dist/./lib/libldap60.so > sasl_dispose ../../../../../dist/./lib/libldap60.so > ld: fatal: Symbol referencing errors. No output written to bin/ldapdelete > gmake[2]: *** [bin/ldapdelete] Error 1 > gmake[2]: Leaving directory > `/root/ldap/mozilla/directory/c-sdk/ldap/clients/tools' > gmake[1]: *** [export] Error 2 > gmake[1]: Leaving directory `/root/ldap/mozilla/directory/c-sdk/ldap' > gmake: *** [export] Error 2 > Either hack the script to avoid passing --with-sasl to mozldap configure or download and compile cyrus-sasl. The latter is recommended if you plan on using Kerberos auth or Digest-MD5 on the client side. > > Any ideas? > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Oct 2 00:18:03 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 01 Oct 2007 17:18:03 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 314851] vlv: crash after repeated backend creation/deletion In-Reply-To: <200710020015.l920FpNu020961@bz-web2.app.phx.redhat.com> References: <200710020015.l920FpNu020961@bz-web2.app.phx.redhat.com> Message-ID: <47018E3B.5050909@redhat.com> Summary: vlv: crash after repeated backend creation/deletion https://bugzilla.redhat.com/show_bug.cgi?id=314851 Description of problem: Steps: Create 2 servers Create a new backend instance on each server (exampleroot: dc=example,dc=com) Initialize the backend with Example.ldif on one server Set up MMR agreement on the backend instance Initalize the replica on the server on which the backend was initialized Create browsing index on the replica Remove replication agreement and the backend exampleroot Repeat the steps till the crash occurs. Attaching the stacktrace. The direct cause is some dse callback points an instance directory which is not associated with the backend. ------- Additional Comments From nhosoi at redhat.com 2007-10-01 20:04 EST ------- Created an attachment (id=213101) --> (https://bugzilla.redhat.com/attachment.cgi?id=213101&action=view) stacktrace and DSE callback list ------- Additional Comments From nhosoi at redhat.com 2007-10-01 20:15 EST ------- Created an attachment (id=213111) --> (https://bugzilla.redhat.com/attachment.cgi?id=213111&action=view) cvs diff ldapserver/ldap/servers/slapd/back-ldbm/vlv.c Description: if the backend is not set, return SLAPI_DSE_CALLBACK_ERROR and don't call vlvSearch_init. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Oct 2 18:32:49 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 02 Oct 2007 11:32:49 -0700 Subject: [Fedora-directory-devel] LDAP/Samba 4 summary Message-ID: <1191349969.4226.36.camel@localhost.localdomain> (please forgive the cross-posting to subscriber-only lists) Howard Chu helpfully wrote up this summary of the meeting we held at the CIFS Workshop on how Samba4 should work with an LDAP backend. The background is that Samba4 increasingly needs some things that an LDAP server could provide for us. In the short term, we need to add subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for us. Likewise, we have a desperate need for replication (because any site in need of Samba4's features will want multiple DCs) - and Fedora DS's replication seems like a very good, solid answer. (Sadly it doesn't give us subtree renames...). Another feature we don't yet do schema validation in Samba4, beyond checking that the objectClass list is valid. We need to extend that, but perhaps the LDAP server could do that validation for us? Finally, in the long term, we would like to have Samba4 play nice in a multi-use directory, and this presents a schema mapping problem. We agreed to get together and try and work out a schema that is compatible to Microsoft's extensions, without being too painful to see from a traditional client. I hope to put together a discussion on this in the near future. I expect we will continue to use and support ldb_tdb as a backend on Samba4, but for some features (which they will want), users should be directed to use LDAP as an important backend. Andrew Bartlett -------- Forwarded Message -------- From: Howard Chu To: OpenLDAP-devel at openldap.org Subject: [Fwd: LDAP/Samba 4 summary] Date: Fri, 28 Sep 2007 10:42:22 -0700 Yesterday afternoon at the CIFS Workshop we had a meeting to discuss Samba 4's use of LDAP going forward, and what obstacles remained. Among the attendees that I can remember were Andrew Bartlett, Andrew Tridgell, Simo Sorce, Stefan Metzmacher, and (one more, I've forgotten the name) from the Samba team. Nicole Jacque and another (sorry, don't remember the name) from Apple/OpenDirectory, Pete Rowley from FedoraDS, and myself and Marty Heyman for OpenLDAP and Symas. The upshot is that both the Samba and the LDAP sides have work to do, but there are no major roadblocks. LDAP will be Samba 4's default/recommended data store. As for OpenLDAP, most of what Samba 4 needs is either already implemented, or in progress. Schema design tends to still be a stumbling block; in a separate conversation we discussed some design issues in MIT's new Kerberos schema as well as missing features in Heimdal's existing Kerberos schema. That's a bit outside this openldap-devel scope but I've committed to working with the Samba and Kerberos communities to draft some changes to unify these two Kerberos schemas. -------- Forwarded Message -------- From: Howard Chu To: Andrew Bartlett Subject: LDAP/Samba 4 summary Date: Thu, 27 Sep 2007 22:41:23 -0700 Missing features / wishlist bitwise ops. already in OpenLDAP, recently added to FedoraDS(?) USNs partially implemented in OpenLDAP, need more complete spec LDAP Transaction support draft-zelenga-ldap-txn - partially implemented in OpenLDAP some concerns because Samba's definition of transaction is not the canonical ACID definition. More like ACI, no Durability guarantee, doesn't play well with LDAP Multimaster Replication. We all agreed that if Samba doesn't care, neither do we. All that matters is that it provides tidy, painless rollback in event of intermediate failures. Access Controls my suggestion re: OpenLDAP - we support modular ACL engines, we should just write a module for native NT ACLs in OpenLDAP AD schema - we agreed that a new schema is necessary no matter how you slice it, we will all collaborate to define a superset of AD that everyone can support. Authentication mechanisms - generally Samba will handle this itself validation - Samba4 + LDAP must pass everything under Samba's "make test" suite. Transactions again - we may need things like memberOf and other linked attributes to be managed internally in the server. No problem, both OpenLDAP and FDS have memberOf plugins already available. Subtree renames - MS tools assume subtree renames work. Supported in OpenLDAP already (back-hdb, back-ldif, will be in back-tdb). Unfortunately not supported in FedoraDS, might be able to kludge it, but it will require additional mapping layers. And kludging will break base-scope searches, referential integrity, etc... -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hyc at symas.com Tue Oct 2 20:02:58 2007 From: hyc at symas.com (Howard Chu) Date: Tue, 02 Oct 2007 13:02:58 -0700 Subject: [Fedora-directory-devel] Re: LDAP/Samba 4 summary In-Reply-To: <1191349969.4226.36.camel@localhost.localdomain> References: <1191349969.4226.36.camel@localhost.localdomain> Message-ID: <4702A3F2.9040800@symas.com> Andrew Bartlett wrote: > (please forgive the cross-posting to subscriber-only lists) > > Howard Chu helpfully wrote up this summary of the meeting we held at the > CIFS Workshop on how Samba4 should work with an LDAP backend. > > The background is that Samba4 increasingly needs some things that an > LDAP server could provide for us. In the short term, we need to add > subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for > us. > > Likewise, we have a desperate need for replication (because any site in > need of Samba4's features will want multiple DCs) - and Fedora DS's > replication seems like a very good, solid answer. (Sadly it doesn't > give us subtree renames...). Multimaster replication is also in OpenLDAP 2.4 (which is currently still in beta - we're still shaking it down, more testers would probably be helpful at some point). > Another feature we don't yet do schema validation in Samba4, beyond > checking that the objectClass list is valid. We need to extend that, > but perhaps the LDAP server could do that validation for us? Right, since LDAP doesn't really depend on schema-aware clients this is the LDAP server's responsibility. (As opposed to X.500, where every agent in the system must be fully schema aware.) -- -- 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/ From daelic at gmail.com Tue Oct 2 20:12:00 2007 From: daelic at gmail.com (Jason) Date: Tue, 2 Oct 2007 13:12:00 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <47018B82.70308@redhat.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> Message-ID: <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> On 10/1/07, Richard Megginson wrote: > Either hack the script to avoid passing --with-sasl to mozldap configure > or download and compile cyrus-sasl. The latter is recommended if you > plan on using Kerberos auth or Digest-MD5 on the client side. I'd compiled cyrus-sasl, but did not install it. It's at the top of my build directory: mrfreeze:/root/ldap/mozilla/directory/c-sdk>ls -al /root/ldap total 8956 drwxr-xr-x 4 root 512 Oct 1 15:24 . drwx------ 6 root 512 Sep 26 16:41 .. drwxr-xr-x 20 17985 1024 Oct 1 15:27 cyrus-sasl-2.1.20 -rw-r--r-- 1 root 9156608 Sep 28 10:13 cyrus-sasl-2.1.20.tar drwxr-xr-x 7 517 512 Oct 1 14:26 mozilla I saw no errors during the compile. Perhaps when I run my configure, i need to tell it where to find it? From rmeggins at redhat.com Tue Oct 2 20:23:03 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 02 Oct 2007 14:23:03 -0600 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> Message-ID: <4702A8A7.4040908@redhat.com> Jason wrote: > On 10/1/07, Richard Megginson wrote: > >> Either hack the script to avoid passing --with-sasl to mozldap configure >> or download and compile cyrus-sasl. The latter is recommended if you >> plan on using Kerberos auth or Digest-MD5 on the client side. >> > > I'd compiled cyrus-sasl, but did not install it. It's at the top of my > build directory: > > mrfreeze:/root/ldap/mozilla/directory/c-sdk>ls -al /root/ldap > total 8956 > drwxr-xr-x 4 root 512 Oct 1 15:24 . > drwx------ 6 root 512 Sep 26 16:41 .. > drwxr-xr-x 20 17985 1024 Oct 1 15:27 cyrus-sasl-2.1.20 > -rw-r--r-- 1 root 9156608 Sep 28 10:13 cyrus-sasl-2.1.20.tar > drwxr-xr-x 7 517 512 Oct 1 14:26 mozilla > > > I saw no errors during the compile. Perhaps when I run my configure, i > need to tell it where to find it? > Yes. See c-sdk/config/autoconf/sasl.m4 for how to specify the sasl location. > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Oct 2 20:39:06 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 02 Oct 2007 13:39:06 -0700 Subject: [Fedora-directory-devel] Re: LDAP/Samba 4 summary In-Reply-To: <4702A3F2.9040800@symas.com> References: <1191349969.4226.36.camel@localhost.localdomain> <4702A3F2.9040800@symas.com> Message-ID: <1191357546.4226.40.camel@localhost.localdomain> On Tue, 2007-10-02 at 13:02 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > (please forgive the cross-posting to subscriber-only lists) > > > > Howard Chu helpfully wrote up this summary of the meeting we held at the > > CIFS Workshop on how Samba4 should work with an LDAP backend. > > > > The background is that Samba4 increasingly needs some things that an > > LDAP server could provide for us. In the short term, we need to add > > subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for > > us. > > > > Likewise, we have a desperate need for replication (because any site in > > need of Samba4's features will want multiple DCs) - and Fedora DS's > > replication seems like a very good, solid answer. (Sadly it doesn't > > give us subtree renames...). > > Multimaster replication is also in OpenLDAP 2.4 (which is currently still in > beta - we're still shaking it down, more testers would probably be helpful at > some point). I'll have to keep an eye on that. > > Another feature we don't yet do schema validation in Samba4, beyond > > checking that the objectClass list is valid. We need to extend that, > > but perhaps the LDAP server could do that validation for us? > > Right, since LDAP doesn't really depend on schema-aware clients this is the > LDAP server's responsibility. (As opposed to X.500, where every agent in the > system must be fully schema aware.) Yes, but we may not wish to have the backend server be as fully aware as Samba about the full monster that is the AD schema, or we may wish to pre-empt the backend server's response. For example, if Samba implements a 'no-user-modification' attribute in a module, we will have to remove that tag from the OpenLDAP/FedoraDS schema, and prevent that modification ourselves. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From daelic at gmail.com Tue Oct 2 21:40:13 2007 From: daelic at gmail.com (Jason) Date: Tue, 2 Oct 2007 14:40:13 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <4702A8A7.4040908@redhat.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> <4702A8A7.4040908@redhat.com> Message-ID: <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> On 10/2/07, Richard Megginson wrote: > Yes. See c-sdk/config/autoconf/sasl.m4 for how to specify the sasl > location. ok, I've changed my configure params: ./configure --enable-clu --with-sasl=/root/ldap/cyrus-sasl-2.1.20 --with-svrcore --enable-optimize --disable-debug I still get the same error, the only difference is it now adds "-L/root/ldap/cyrus-sasl-2.1.20/lib" just before the error. Here is what I have in /root/ldap/cyrus-sasl-2.1.20/lib: mrfreeze:/root/ldap/mozilla/directory/c-sdk>ls /root/ldap/cyrus-sasl-2.1.20/lib .cvsignore NTMakefile canonusr.o client.o config.o external.o md5.c saslutil.c seterror.c .deps auxprop.c checkpw.c common.c dlopen.c getaddrinfo.c md5.lo saslutil.lo seterror.lo .libs auxprop.lo checkpw.lo common.lo dlopen.lo getnameinfo.c md5.o saslutil.o seterror.o Makefile auxprop.o checkpw.o common.o dlopen.o getsubopt.c plugin_common.lo server.c snprintf.c Makefile.am canonusr.c client.c config.c external.c libsasl2.a plugin_common.o server.lo staticopen.h Makefile.in canonusr.lo client.lo config.lo external.lo libsasl2.la saslint.h server.o windlopen.c I apologize if I'm being a pain in the behind, this is admittedly not my area of expertise. From rmeggins at redhat.com Tue Oct 2 21:53:36 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 02 Oct 2007 15:53:36 -0600 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> <4702A8A7.4040908@redhat.com> <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> Message-ID: <4702BDE0.5010704@redhat.com> Jason wrote: > On 10/2/07, Richard Megginson wrote: > >> Yes. See c-sdk/config/autoconf/sasl.m4 for how to specify the sasl >> location. >> > > ok, I've changed my configure params: > > ./configure --enable-clu --with-sasl=/root/ldap/cyrus-sasl-2.1.20 > --with-svrcore --enable-optimize --disable-debug > > I still get the same error, the only difference is it now adds > "-L/root/ldap/cyrus-sasl-2.1.20/lib" just before the error. > > Here is what I have in /root/ldap/cyrus-sasl-2.1.20/lib: > > mrfreeze:/root/ldap/mozilla/directory/c-sdk>ls /root/ldap/cyrus-sasl-2.1.20/lib > .cvsignore NTMakefile canonusr.o client.o > config.o external.o md5.c saslutil.c > seterror.c > .deps auxprop.c checkpw.c common.c > dlopen.c getaddrinfo.c md5.lo saslutil.lo > seterror.lo > .libs auxprop.lo checkpw.lo common.lo > dlopen.lo getnameinfo.c md5.o saslutil.o > seterror.o > Makefile auxprop.o checkpw.o common.o > dlopen.o getsubopt.c plugin_common.lo server.c > snprintf.c > Makefile.am canonusr.c client.c config.c > external.c libsasl2.a plugin_common.o server.lo > staticopen.h > Makefile.in canonusr.lo client.lo config.lo > external.lo libsasl2.la saslint.h server.o > windlopen.c > There's no libsasl2.so - this is required to link against sasl. You may have to do a make install (not to the system /usr/lib directory but to e.g. /root/ldap/sasl to generate libsasl2.so > I apologize if I'm being a pain in the behind, this is admittedly not > my area of expertise. > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From daelic at gmail.com Tue Oct 2 22:40:41 2007 From: daelic at gmail.com (Jason) Date: Tue, 2 Oct 2007 15:40:41 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <4702BDE0.5010704@redhat.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> <4702A8A7.4040908@redhat.com> <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> <4702BDE0.5010704@redhat.com> Message-ID: <5a69da6f0710021540l799a6064wedcf17b2c24a26cd@mail.gmail.com> On 10/2/07, Richard Megginson wrote: > There's no libsasl2.so - this is required to link against sasl. You may > have to do a make install (not to the system /usr/lib directory but to > e.g. /root/ldap/sasl to generate libsasl2.so ok, I did a make install for sasl, and it placed everything in /root/ldap/cyrus-sasl-2.1.20/built. (I followed the sasl instructions in the build documentation for the build). I changed to --with-sasl=/root/ldap/cyrus-sasl-2.1.20/built, and now it says it's looking in /root/ldap/cyrus-sasl-2.1.20/built/lib when trying to link. I even updated LD_LIBRARY_PATH to include /root/ldap/cyrus-sasl-2.1.20/built/lib, but I'm still getting the same compile error, saying there are undefined symbols. From rmeggins at redhat.com Tue Oct 2 23:37:19 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 02 Oct 2007 17:37:19 -0600 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710021540l799a6064wedcf17b2c24a26cd@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> <4702A8A7.4040908@redhat.com> <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> <4702BDE0.5010704@redhat.com> <5a69da6f0710021540l799a6064wedcf17b2c24a26cd@mail.gmail.com> Message-ID: <4702D62F.9080708@redhat.com> Jason wrote: > On 10/2/07, Richard Megginson wrote: > >> There's no libsasl2.so - this is required to link against sasl. You may >> have to do a make install (not to the system /usr/lib directory but to >> e.g. /root/ldap/sasl to generate libsasl2.so >> > > ok, I did a make install for sasl, and it placed everything in > /root/ldap/cyrus-sasl-2.1.20/built. (I followed the sasl instructions > in the build documentation for the build). I changed to > --with-sasl=/root/ldap/cyrus-sasl-2.1.20/built, and now it says it's > looking in /root/ldap/cyrus-sasl-2.1.20/built/lib when trying to link. > Then use --with-sasl-lib=/path/to/built and --with-sasl-inc=/path/to/built > I even updated LD_LIBRARY_PATH to include > /root/ldap/cyrus-sasl-2.1.20/built/lib, but I'm still getting the same > compile error, saying there are undefined symbols. > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Oct 3 19:11:11 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 03 Oct 2007 12:11:11 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 304161] logrotation time of -1 causes hang In-Reply-To: <200710031907.l93J7IFS021178@bz-web1.app.phx.redhat.com> References: <200710031907.l93J7IFS021178@bz-web1.app.phx.redhat.com> Message-ID: <4703E94F.1070208@redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From daelic at gmail.com Thu Oct 4 01:12:23 2007 From: daelic at gmail.com (Jason) Date: Wed, 3 Oct 2007 18:12:23 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <4702D62F.9080708@redhat.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <4701416A.8050304@redhat.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> <4702A8A7.4040908@redhat.com> <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> <4702BDE0.5010704@redhat.com> <5a69da6f0710021540l799a6064wedcf17b2c24a26cd@mail.gmail.com> <4702D62F.9080708@redhat.com> Message-ID: <5a69da6f0710031812x5e82c4b6i698d035d3ef5e76d@mail.gmail.com> On 10/2/07, Richard Megginson wrote: > > > Then use --with-sasl-lib=/path/to/built and --with-sasl-inc=/path/to/built > > I even updated LD_LIBRARY_PATH to include > > /root/ldap/cyrus-sasl-2.1.20/built/lib, but I'm still getting the same > > compile error, saying there are undefined symbols. I was hoping I could say this worked, but alas... I cannot. I even decided to install sasl to the system, so that the libraries are in /usr/local/lib/sasl2 but even that does not allow the compile to link correctly. From nhosoi at redhat.com Thu Oct 4 23:39:56 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 04 Oct 2007 16:39:56 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 173873] Directory Server should shutdown if it fails to write logs In-Reply-To: <200710042204.l94M4bod008374@bz-web2.app.phx.redhat.com> References: <200710042204.l94M4bod008374@bz-web2.app.phx.redhat.com> Message-ID: <470579CC.1010008@redhat.com> Summary: Directory Server should shutdown if it fails to write logs https://bugzilla.redhat.com/show_bug.cgi?id=173873 ------- Additional Comments From nhosoi at redhat.com 2007-10-04 18:04 EST ------- Created an attachment (id=216781) --> (https://bugzilla.redhat.com/attachment.cgi?id=216781&action=view) cvs diff ldapserver/ldap/servers/slapd/{log.c, libglobs.c} Files: ldapserver/ldap/servers/slapd/log.c /libglobs.c Change Description: 1. introduced a new static function log__error_emergency, which is called at emergency to log to the syslog and at least try to log into the errors log one more time. 2. added an error parameter to the macro LOG_WRITE_NOW to return if the writing to the log was successful or not. 3. if opening an errors log or writing to an errors log failed, call g_set_shutdown to shutdown the server gracefully. 4. log__error_emergency calls writing log function (LDAPDebug --> slapd_log_error_proc_internal) with ERROR_LOCK_WRITE unlocked, if locked. ------- Additional Comments From nhosoi at redhat.com 2007-10-04 19:32 EST ------- Created an attachment (id=216791) --> (https://bugzilla.redhat.com/attachment.cgi?id=216791&action=view) test cases Error cases: . opening errors log . rotating errors log . writing to errors log -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Oct 5 22:43:33 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 05 Oct 2007 16:43:33 -0600 Subject: [Fedora-directory-devel] Please review: Bug 248169: init script modification needed for kerberos auth Message-ID: <4706BE15.3000007@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=248169 Resolves: bug 248169 Bug Description: init script modification needed for kerberos auth Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I just took Simo's initial patch and ran with it. The initconfigdir parameter is the directory containing the config file for the init script. configure will first try to use $(sysconfdir)/sysconfig, then $(sysconfdir)/default (Solaris and Debian, among others), then the package config directory (the default on HP-UX), for this parameter. The init script and startup script will look in the initconfigdir to find the init config file to source. For directory server, an instance specific file can be used, named e.g. dirsrv-localhost which will apply to the slapd-localhost instance only. A default init config file is provided for dirsrv and dirsrv-admin, with some examples of how it could be used. Platforms tested: RHEL5 x86_64 Flag Day: Yes - autotool file changes Doc impact: Yes. We will need to document how the user can supply environment to the servers at startup time without having to edit the init scripts or the startup scripts. QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/attachment.cgi?id=218101&action=diff https://bugzilla.redhat.com/attachment.cgi?id=218121&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 9 04:03:11 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 08 Oct 2007 22:03:11 -0600 Subject: [Fedora-directory-devel] Please review: Bug 305121: Server hangs when adding a group with two password entries Message-ID: <470AFD7F.8080504@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=305121 Resolves: bug 305121 Bug Description: Server hangs when adding a group with two password entries Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The pw_encodevals() was not encoding each value, only the first one, then setting each new value to the same encoded value. The solution is to move char *enc into the loop so that it is allocated anew each time. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=220601&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 9 17:37:16 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 09 Oct 2007 11:37:16 -0600 Subject: [Fedora-directory-devel] Please review: Bug 190220: Link DS with libumem on Solaris 9 and later Message-ID: <470BBC4C.7060807@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=190220 Resolves: bug 190220 Bug Description: Link DS with libumem on Solaris 9 and later Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: See if libumem.so exists, and set the appropriate LD_PRELOAD env. var. if so. Platforms tested: Solaris 9 64-bit Flag Day: no Doc impact: no https://bugzilla.redhat.com/show_bug.cgi?id=190220#c3 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Oct 9 17:59:58 2007 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 09 Oct 2007 10:59:58 -0700 Subject: [Fedora-directory-devel] Please Review: (325281) Need to install mibs for ldap-agent Message-ID: <470BC19E.9040201@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=325281 Resolves: bug 325281 Bug Description: Need to install mibs for ldap-agent Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Install the mibs needed to query ldap-agent SNMP subagent. Platforms tested: FC6 i386 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=221581&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 9 21:21:53 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 09 Oct 2007 15:21:53 -0600 Subject: [Fedora-directory-devel] Please review: Bug 244475: crash at startup with new ldap sdk on 64-bit platform Message-ID: <470BF0F1.8040102@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=244475 Resolves: bug 244475 Bug Description: crash at startup with new ldap sdk on 64-bit platform Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I went ahead and cleaned up or removed the incorrect ber code. We do not need to use LBER_SOCKBUF_OPT_DESC or LBER_SOCKBUF_OPT_READ_FN or LBER_SOCKBUF_OPT_WRITE_FN. I removed an unnecessary malloc/free and just used the stack as we do everywhere else in the code. It looks as though the start_tls cleanup code is almost never used - the code assumes that when you do a start_tls, that stays in force throughout the lifetime of the connection. Removing this code now should insulate us from future ldap c sdk changes. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=221791&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From daelic at gmail.com Tue Oct 9 23:28:25 2007 From: daelic at gmail.com (Jason) Date: Tue, 9 Oct 2007 16:28:25 -0700 Subject: [Fedora-directory-devel] libatomic.o missing; Solaris 8 Build In-Reply-To: <5a69da6f0710031812x5e82c4b6i698d035d3ef5e76d@mail.gmail.com> References: <5a69da6f0710011146u60b7fd5x3d848d05c75291a@mail.gmail.com> <5a69da6f0710011624n750f106em90d5bd5f8b7c52f9@mail.gmail.com> <47018B82.70308@redhat.com> <5a69da6f0710021312r2f2fc759j3577b34285f0b7f5@mail.gmail.com> <4702A8A7.4040908@redhat.com> <5a69da6f0710021440o360ba48coa45f227100cd36c@mail.gmail.com> <4702BDE0.5010704@redhat.com> <5a69da6f0710021540l799a6064wedcf17b2c24a26cd@mail.gmail.com> <4702D62F.9080708@redhat.com> <5a69da6f0710031812x5e82c4b6i698d035d3ef5e76d@mail.gmail.com> Message-ID: <5a69da6f0710091628g497ee471kf3c7b95f925562c9@mail.gmail.com> Hi there! remember me? I finally got past this problem, so I thought I would share just in case anyone was fool enough to try and get this working on solaris 8. :) I had to do 2 things to get past compiling LDAPSDK: 1: I ended up compiling sasl dynamic 2: I had to modify c-sdk/ldap/clients/tools/Makefile. Added -lsasl2 to the end of SASL_LIBS e.g. SASL_LIBS = -L/root/ldap/cyrus-sasl-2.1.20/build-nostatic/lib -lsasl2 On 10/3/07, Jason wrote: > On 10/2/07, Richard Megginson wrote: > > > > > Then use --with-sasl-lib=/path/to/built and --with-sasl-inc=/path/to/built > > > I even updated LD_LIBRARY_PATH to include > > > /root/ldap/cyrus-sasl-2.1.20/built/lib, but I'm still getting the same > > > compile error, saying there are undefined symbols. > > I was hoping I could say this worked, but alas... I cannot. I even > decided to install sasl to the system, so that the libraries are in > /usr/local/lib/sasl2 but even that does not allow the compile to link > correctly. > From rmeggins at redhat.com Fri Oct 12 04:04:15 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 11 Oct 2007 22:04:15 -0600 Subject: [Fedora-directory-devel] Please review: Bug 288291: add an view object inside a view object that has an improper nsviewfilter crashes the server Message-ID: <470EF23F.30800@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=288291 Resolves: bug 288291 Bug Description: add an view object inside a view object that has an improper nsviewfilter crashes the server Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I could not reproduce the problem by simply adding the bogus nsviewfilter. The server seemed to run fine, but I didn't stress it. However, if I restarted the server, the server would core during startup. The last message in the error log would say something about recovering the database, which is probably why the bug reporter said that it will not recover the database. The problem doesn't appear to be with views specifically, but with any internal search which uses the search_internal_callback_pb() (as opposed to the non callback internal search) and there are search base rewriters (such as the views code). The aci code uses this type of search at startup to find the acis, and that's where I saw the crash. I could crash the server at startup regardless of whether the view filter was bogus or not. The problem is that we are not passing in the address of new_base to slapi_ch_free. The fix is to use slapi_ch_free_string and pass in the address of the string. That fixes the crash. I also cleaned up a few places in the views code which was not checking to see if slapi_str2filter returned NULL, which would happen in the case of the bogus search filter. I also added an error message which will tell the user that filter X in entry Y is bogus. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=224951&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Oct 12 22:01:49 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 12 Oct 2007 16:01:49 -0600 Subject: [Fedora-directory-devel] Please review: Bug 330121: uuid generator truncates clock_seq_hi_and_reserved field Message-ID: <470FEECD.2000905@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=330121 Resolves: bug 330121 Bug Description: uuid generator truncates clock_seq_hi_and_reserved field Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=330121#c0 This may also be related to https://bugzilla.redhat.com/show_bug.cgi?id=197886 and may explain why the sequence numbers were exhausted so quickly. Without this fix, we only have 256 sequence numbers available. This fix adds another 6 bits. The fix is to mask and shift as an unsigned16 quantity, then cast to unsigned8. Platforms tested: RHEL5 x86_64 Flag Day: no - I think this will only impact new unique IDs that are generated. It will not affect existing unique IDs. Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=226161&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Oct 12 22:07:48 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 12 Oct 2007 16:07:48 -0600 Subject: [Fedora-directory-devel] Please review: Bug 330141: uuid generator not initialized by import from command line Message-ID: <470FF034.8050500@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=330141 Resolves: bug 330141 Bug Description: uuid generator not initialized by import from command line Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=330141#c0 What happens is that the uuid values all look like this: XXXXXXXX-XXXXXXXX-80000000-00000000 So the time based part is generally ok, but the clock seq and node ID part are never initialized, hence 0's for those fields. The fix is to initialize the unique id generator in the same manner as we do for the server when it starts up in regular mode, except that we tell the generator to use the single threaded (st) mode rather than the multi threaded (mt) mode. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/attachment.cgi?id=226181&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Mon Oct 15 23:24:50 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 15 Oct 2007 16:24:50 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 188320] HP-UX: warnings reported by the HP-UX compiler In-Reply-To: <200710152235.l9FMZwYw015192@bz-web1.app.phx.redhat.com> References: <200710152235.l9FMZwYw015192@bz-web1.app.phx.redhat.com> Message-ID: <4713F6C2.5040501@redhat.com> Summary: HP-UX: warnings reported by the HP-UX compiler https://bugzilla.redhat.com/show_bug.cgi?id=188320 Cleaned up the compiler warnings issued by the HP-UX compiler. There are some questionable suggestions. Please search "ifdef NOTUSED" in the cvs diffs (comment #6). I left such ones in the "ifdef NOTUSED". Some compiler warnings look suspicious. I ignored them and keep them in the code (the warnings are seen in the attachment in comment #7). Attachment in comment #5 is the warnings with my notes (if any). Comment #5 From Noriko Hosoi (nhosoi at redhat.com ) on 2007-10-15 18:35 EST [reply ] Private Created an attachment (id=227951) [edit ] compiler warnings with comments Comment #6 From Noriko Hosoi (nhosoi at redhat.com ) on 2007-10-15 18:35 EST [reply ] Private Created an attachment (id=227961) [edit ] cvs diffs Comment #7 From Noriko Hosoi (nhosoi at redhat.com ) on 2007-10-15 19:15 EST [reply ] Private Created an attachment (id=227991) [edit ] build log with the changes (built on hound) Thanks, --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Mon Oct 15 23:36:27 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 15 Oct 2007 16:36:27 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 327091] Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture In-Reply-To: <47102322.9050001@redhat.com> References: <200710110116.l9B1GXE8025669@bz-web1.app.phx.redhat.com> <470FBF41.90707@redhat.com> <470FD658.90903@hp.com> <470FDFA8.6030209@redhat.com> <470FED57.5090602@hp.com> <470FFD3B.5070508@redhat.com> <471005AE.4050409@redhat.com> <47102322.9050001@redhat.com> Message-ID: <4713F97B.8050200@redhat.com> Summary: Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture https://bugzilla.redhat.com/show_bug.cgi?id=327091 Problem description: Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture ------- Additional Comments From nhosoi at redhat.com 2007-10-15 19:30 EST ------- Created an attachment (id=228001) --> (https://bugzilla.redhat.com/attachment.cgi?id=228001&action=view) cvs diff back-ldbm.h dblayer.c upgrade.c Files: ldap/servers/slapd/back-ldbm/back-ldbm.h, dblayer.c, upgrade.c Description: merged the proposed fixes from comment #1, #3, and #4. back-ldbm.h: added LDBM_VERSION_62 dblayer.c: fixed a bug to check the instance dir name upgrade.c: added LDBM_VERSION_62, with the action DBVERSION_NO_UPGRADE as Ulf suggested. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Oct 16 17:38:40 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 16 Oct 2007 10:38:40 -0700 Subject: [Fedora-directory-devel] Commit: [Bug 327091] Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture In-Reply-To: <4713F97B.8050200@redhat.com> References: <200710110116.l9B1GXE8025669@bz-web1.app.phx.redhat.com> <470FBF41.90707@redhat.com> <470FD658.90903@hp.com> <470FDFA8.6030209@redhat.com> <470FED57.5090602@hp.com> <470FFD3B.5070508@redhat.com> <471005AE.4050409@redhat.com> <47102322.9050001@redhat.com> <4713F97B.8050200@redhat.com> Message-ID: <4714F720.4000607@redhat.com> Summary: Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture https://bugzilla.redhat.com/show_bug.cgi?id=327091 ------- Additional Comments From nhosoi at redhat.com 2007-10-16 13:32 EST ------- Created an attachment (id=229061) --> (https://bugzilla.redhat.com/attachment.cgi?id=229061&action=view) cvs commit message Reviewed by Rich (Thank you!!) Checked in into CVS HEAD. ------- Additional Comments From nhosoi at redhat.com 2007-10-16 13:33 EST ------- Related bug: 333291: Do not allow direct migration if the source db index has old IDL format > Problem description: Migration/Upgrade fails when it's from 6.21 to > 8.0 on the same OS/architecture > > ------- Additional Comments From nhosoi at redhat.com 2007-10-15 19:30 > EST ------- > Created an attachment (id=228001) > --> (https://bugzilla.redhat.com/attachment.cgi?id=228001&action=view) > cvs diff back-ldbm.h dblayer.c upgrade.c > > Files: > ldap/servers/slapd/back-ldbm/back-ldbm.h, dblayer.c, upgrade.c > > Description: > merged the proposed fixes from comment #1, #3, and #4. > back-ldbm.h: added LDBM_VERSION_62 > dblayer.c: fixed a bug to check the instance dir name > upgrade.c: added LDBM_VERSION_62, with the action > DBVERSION_NO_UPGRADE as Ulf > suggested. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 18 20:21:34 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 18 Oct 2007 14:21:34 -0600 Subject: [Fedora-directory-devel] Please review: Bug 232910: ACI targetattr list parser is whitespace sensitive Message-ID: <4717C04E.7090101@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=232910 Resolves: bug 232910 Bug Description: ACI targetattr list parser is whitespace sensitive Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Need to trim trailing whitespace from the targetattr clause. I noticed that targetattrfilters had the same problem, except it returned ACL_SYNTAX_ERR in that case, so I changed targetattr to do the same. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=231531&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Thu Oct 18 21:45:06 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 18 Oct 2007 14:45:06 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 329951] MMR: Supplier does not respond anymore after many operations (deletes) In-Reply-To: <200710182129.l9ILTHU9018362@bz-web1.app.phx.redhat.com> References: <200710182129.l9ILTHU9018362@bz-web1.app.phx.redhat.com> Message-ID: <4717D3E2.40703@redhat.com> Summary: MMR: Supplier does not respond anymore after many operations (deletes) https://bugzilla.redhat.com/show_bug.cgi?id=329951 Backend thread updating RUV and thread updating VLV index could cause a deadlock on vlvSearchList_lock and the libdb page. ------- Additional Comments From nhosoi at redhat.com 2007-10-18 17:29 EST ------- Created an attachment (id=231611) --> (https://bugzilla.redhat.com/attachment.cgi?id=231611&action=view) cvs diffs Files: plugins/replication/repl5_plugins.c plugins/replication/repl5_replica.c slapd/slapi-private.h slapd/back-ldbm/ldbm_add.c slapd/back-ldbm/ldbm_delete.c slapd/back-ldbm/ldbm_modify.c slapd/back-ldbm/ldbm_modrdn.c Description: introduce OP_FLAG_REPL_RUV. It's set in repl5_replica.c if the entry is RUV. The operation should not be blocked at the backend SERIAL lock (this is achieved by having OP_FLAG_REPL_FIXUP set in the operation flag). But updating RUV has nothing to do with VLV, thus if the flag is set, it skips the VLV indexing. Test case I'm running: Set up 2-way MMR (Master 1 and 2) Set purge delay: nsds5ReplicaPurgeDelay: 600 Import an LDIF file on Master 1 Initialize the replica (Master 2) on Master 1 Create browsing indexes on both Master 1 and 2 Then, I started running following test tools: ldclt -D "cn=Directory manager" -w -p -e add -e random -b ou=Payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R 2999 -I 68 -e inetOrgPerson -e imagesdir= ldclt -D "cn=Directory manager" -w -p -e delete -e random -b ou=payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R 2999 -I 32 -e inetOrgPerson -e imagesdir= ldclt -D "cn=Directory manager" -w -p -e attreplace=sn:a_random_sn_XXXX -e random -b ou=payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R 2999 -I 32 So far, it's been running for 2 hours with occasional checks on the browser using VLV/brousing index. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Oct 19 01:31:45 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 18 Oct 2007 18:31:45 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 339031] Solaris: warnings reported by the Solaris compiler In-Reply-To: <200710190122.l9J1Mr2n016952@bz-web2.app.phx.redhat.com> References: <200710190122.l9J1Mr2n016952@bz-web2.app.phx.redhat.com> Message-ID: <47180901.1040906@redhat.com> Summary: Solaris: warnings reported by the Solaris compiler https://bugzilla.redhat.com/show_bug.cgi?id=339031 Description of problem: Warnings from the Solaris compiler (Studio 11) 1. "ldap/servers/slapd/back-ldbm/back-ldbm.h", line 57: warning: macro redefined: _LARGEFILE64_SOURCE 2. "ldap/servers/slapd/localhost.c", line 158: warning: implicit function declaration: getdomainname 3. "ldap/servers/slapd/ntuserpin.c", line 214: warning: empty translation unit 4. "ldap/servers/slapd/back-ldbm/haschildren.c", line 45: warning: empty translation unit 5. "ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c", line 591: warning: assignment type mismatch: pointer to unsigned char "=" pointer to char 6. "ldap/servers/plugins/replication/cl5_api.c", line 2248: warning: implicit function declaration: unlink 7. "ldap/servers/plugins/replication/cl5_api.c", line 6455: warning: implicit function declaration: dblayer_strerror 8. "ldap/servers/plugins/replication/windows_protocol_util.c", line 2259: warning: implicit function declaration: strcasestr Mostly, benign except (2), (7), and (8). ------- Additional Comments From nhosoi at redhat.com 2007-10-18 21:22 EST ------- Created an attachment (id=231761) --> (https://bugzilla.redhat.com/attachment.cgi?id=231761&action=view) proposed cvs diffs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Oct 19 19:56:39 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 19 Oct 2007 13:56:39 -0600 Subject: [Fedora-directory-devel] Please review: Bug 340361: build links wrong libdb on 64-bit systems Message-ID: <47190BF7.7030609@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=340361 Resolves: bug 340361 Bug Description: build links wrong libdb on 64-bit systems Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Once again, libtool attempts to be helpful but is instead harmful. If you have both db4-devel.i386 and db4-devel.x86_64 installed, this will install /usr/lib/libdb-4.N.la. If you use libtool to link with -ldb-4.N, and you do not specify a search path, libtool will attempt to find this library in it's default search path, which is something like /usr/lib/gcc/x86_64/blahblahblah/../../../lib. This will find /usr/lib/libdb-4.N.la and will use the information in that file and link the object with /usr/lib/libdb-4.N.so, instead of just passing -ldb-4.N through to the linker which is what it ought to do (darn libtool). In order to make libtool do the right thing, we must pass in -L$libdir -ldb-4.N to libtool so that it will use $libdir first in its search path. Platforms tested: RHEL5 x86_64, RHEL4 x86_64 Flag Day: yes - autotool file changes Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=233041&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: