From nhosoi at redhat.com Wed Oct 4 00:16:10 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 03 Oct 2006 17:16:10 -0700 Subject: [Fedora-directory-devel] Please review (revised): [Bug 208672] parameterizing the hardcoded paths (phase 2. db, log, lock, pid dir) Message-ID: <4522FD4A.2080400@redhat.com> Hello, After discussing with Nathan, I've removed nsslapd-dbdir and nsslapd-ldifdir from cn=config, which are redundant. Your review would be greatly appreciated. Thanks, --noriko https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208672 Summary: parameterizing the hardcoded paths (phase 2. db, log, lock, pid dir) Product: Fedora Directory Server Version: 1.0.2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Directory Server AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ohegarty at redhat.com CC: ohegarty at redhat.com ------- Additional Comments From nhosoi at redhat.com 2006-10-03 19:45 EST ------- Created an attachment (id=137712) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=137712&action=view) cvs diffs (ldapserver -- revised) Thanks for the comments and the discussion, Nathan. Here's the additional changes: 1) I re-thought about the 2 issues and have decided to get rid of nsslapd-dbdir and nsslapd-ldifdir from cn=config. Instead of referring nsslapd-dbdir, we can use nsslapd-directory in cn=config,cn=ldbm database,cn=plugins,cn=config. And for nsslapd-ldifdir, it's basically "defined" in db2ldif, where you can get the location info. 2) In terms of db2ldif and db2ldif.pl, I added server_id prefix to the default exported file name. Before, each instance had its own ldif dir, but under HFS, there is one ldif directory shared among servers on one host. To make it easier to know the origin of the ldif, I propose to add - in front of the generated ldif file name like this: /share/fedora-ds/ldif/-2006_10_03_162640.ldif 3) In the same token, when another instance is added to an existing server sharing the same directory structure, default ldif files such as Example.ldif and Example-roles.ldif files are overwritten. So, I added a backup code to keep the existing files. (note that if the file having the extension ".bak" already exists, the file is overridden...) Files: ldap/admin/include/dsalib.h ldap/admin/lib/dsalib_db.c ldap/admin/lib/dsalib_location.c ldap/admin/lib/dsalib_util.c ldap/admin/src/create_instance.c ldap/admin/src/create_instance.h ldap/admin/src/ds_remove.c ldap/admin/src/scripts/template-db2ldif.pl ldap/servers/slapd/libglobs.c ldap/servers/slapd/protect_db.c ldap/servers/slapd/proto-slap.h ldap/servers/slapd/slap.h ldap/servers/slapd/snmp_collator.c ldap/servers/slapd/back-ldbm/ldbm_config.c ldap/servers/slapd/back-ldbm/ldbm_config.h -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Thu Oct 5 00:31:53 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 04 Oct 2006 17:31:53 -0700 Subject: [Fedora-directory-devel] Please review : [Bug 204808] spurious search timeouts In-Reply-To: <200610050020.k950KFpG025683@bugzilla.redhat.com> References: <200610050020.k950KFpG025683@bugzilla.redhat.com> Message-ID: <45245279.3090806@redhat.com> Special thanks to Robert for finding and debugging the bug. The attachment (id=137787) is a fix proposal based upon his analysis. --noriko ------------------------------------------------------------------------ Summary: spurious search timeouts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204808 [Problem description and analysis by Robert] Created an attachment (id=135312) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135312&action=view) text and code snippits detailing the problem cause [Fix proposal] Created an attachment (id=137787) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=137787&action=view) cvs diffs cb_search.c, pblock.c, search.c Files: ldap/servers/plugins/chainingdb/cb_search.c ldap/servers/slapd/pblock.c ldap/servers/slapd/back-ldif/search.c Changes: 1) cb_search.c: chainingdb_next_search_entry declared int for optime. replaced it with time_t. 2) pblock.c: See attachment "135312: text and code snippits detailing the problem cause" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 5 21:28:46 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 05 Oct 2006 15:28:46 -0600 Subject: [Fedora-directory-devel] Please review:Bug 209538: Allow mod_admserv to build with mozldap5/6 Message-ID: <4525790E.8010509@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209538 Bug(s) fixed: 209538 Bug Description: Allow mod_admserv to build with mozldap5/6 Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: If there is a mozldap6 package on the system, assume the lib suffix is 60, otherwise, 50. If no mozldap package is on the system, look for libldap60.so* in the given ldapsdk_lib directory. If found, assume 60, otherwise, 50. There were also a few problems with the way we were looking for ICU, mostly copy/paste errors, but one was that pkg-config does not have an icu package on some systems, so you have to use icu-config instead. Platforms tested: FC5 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/bugzilla/attachment.cgi?id=137871 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 5 22:59:53 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 05 Oct 2006 16:59:53 -0600 Subject: [Fedora-directory-devel] Please review: [2] Bug 209538: Allow mod_admserv to build with mozldap5/6 Message-ID: <45258E69.9060007@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209538 Bug(s) fixed: 209538 Bug Description: Allow mod_admserv to build with mozldap5/6 Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: If there is a mozldap6 package on the system, assume the lib suffix is 60, otherwise, 50. If no mozldap package is on the system, look for libldap60.so* in the given ldapsdk_lib directory. If found, assume 60, otherwise, 50. There were also a few problems with the way we were looking for ICU, mostly copy/paste errors, but one was that pkg-config does not have an icu package on some systems, so you have to use icu-config instead. Noriko pointed out that if both 50 and 60 libs are in the same dir, the 50 libs will be selected first - we want 60 libs to have preference. The new diffs will select 60 libs if found, or 50 libs if not. Platforms tested: FC5 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/bugzilla/attachment.cgi?id=137879 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 9 19:38:44 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 09 Oct 2006 13:38:44 -0600 Subject: [Fedora-directory-devel] Please review: Bug 202889: Branding: Netscape Directory Server Gateway Message-ID: <452AA544.3080703@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202889 Bug(s) fixed: 202889: Bug Description: Branding: Netscape Directory Server Gateway Reviewed by: ??? Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138065 Branch: HEAD Fix Description: There were quite a few places in the dsgw/phonebook that referred to Netscape Directory Server. These have been removed. Platforms tested: FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138066 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 9 21:10:55 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 09 Oct 2006 15:10:55 -0600 Subject: [Fedora-directory-devel] Please review: Bug 210075: Change version to 1.0.3 Message-ID: <452ABADF.4030908@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210075 Bug(s) fixed: 210075 Bug Description: Change version to 1.0.3 Reviewed by: ??? Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138079 Branch: HEAD Fix Description: Update version strings and etc. to 1.0.3 Platforms tested: FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138080 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 9 21:23:42 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 09 Oct 2006 15:23:42 -0600 Subject: [Fedora-directory-devel] Please review: Bug 199321: incorrect base64 encoding of SHA passwords crashes server Message-ID: <452ABDDE.20806@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199321 Bug(s) fixed: 199321 Bug Description: incorrect base64 encoding of SHA passwords crashes server Reviewed by: ??? Files: ldapserver/ldap/servers/plugins/pwdstorage/sha_pwd.c Branch: HEAD Fix Description: Check the return value of ldif_base64_decode to see if it is less than zero first before the other comparisons. This is the error condition, so we can just return an error. Additionally, the other comparisons with the unsigned should be ok since we know that the hash_len is a positive number. Platforms tested: FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199321#c5 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 10 15:38:36 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 10 Oct 2006 09:38:36 -0600 Subject: [Fedora-directory-devel] Please review: Bug 210120: PAM passthru plugin causes directory server to crash Message-ID: <452BBE7C.509@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210120 Bug(s) fixed: 210120 Bug Description: PAM passthru plugin causes directory server to crash Reviewed by: ??? Files: pam_ptimpl.c Branch: HEAD Fix Description: If the DN given in the BIND request is bogus i.e. not a valid DN (at least not one that ldap_explode_dn can parse), we should just skip the PAM processing and just report a reasonable error to the client. Similarly, if the map method says to lookup the pam ID from the bind DN entry, and the entry cannot be found, just report an error and skip pam processing. Platforms tested: FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138150 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 10 16:50:36 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 10 Oct 2006 10:50:36 -0600 Subject: [Fedora-directory-devel] Please review: Bug 210180: Fix FDS103 Admin Server build issues Message-ID: <452BCF5C.40301@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210180 Bug(s) fixed: 210180 Bug Description: Fix FDS103 Admin Server build issues Reviewed by: ??? Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138159 Branch: HEAD Fix Description: Some of these are related to moving to mozldap6. The others are related to code that was checked in for 1.1, to remove unused files. Platforms tested: RHEL3 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138161 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 10 20:16:53 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 10 Oct 2006 14:16:53 -0600 Subject: [Fedora-directory-devel] Please review: Bug 210220: Update ldapconsole version to 1.0.3; package net-snmp when building from source Message-ID: <452BFFB5.60405@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210220 Bug(s) fixed: 210220 Bug Description: Update ldapconsole version to 1.0.3; package net-snmp when building from source Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: 1) Need to bump version of ldapconsole to 1.0.3 for fds 1.0.3 2) On RHEL3 we still need to build/package net-snmp. Platforms tested: RHEL3 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138187 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 12 18:06:57 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 12 Oct 2006 12:06:57 -0600 Subject: [Fedora-directory-devel] Please review: Bug 185364: Can't update scripts (e.g., start-slapd) in the instance directory Message-ID: <452E8441.8060001@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185364 Bug(s) fixed: 185364 Bug Description: Can't update scripts (e.g., start-slapd) in the instance directory Reviewed by: ??? Files: ldapserver/ldap/cm/newinst/ns-update Branch: HEAD Fix Description: ns-update needs to run ds_create -r for each instance in the server root because the start-slapd et. al. scripts that it needs to recreate are per-instance. The install.inf passed in from setup only contains the information in the [General] and [admin] section. We need to supply the missing information for the [slapd] section to make both create_scripts() and reconfigure_instance() happy. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138351 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 12 19:43:34 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 12 Oct 2006 13:43:34 -0600 Subject: [Fedora-directory-devel] Re: [Fedora-directory-commits] ldapserver/ldap/cm/newinst ns-update, 1.11, 1.12 In-Reply-To: <200610121938.k9CJcHYE005475@cvs-int.fedora.redhat.com> References: <200610121938.k9CJcHYE005475@cvs-int.fedora.redhat.com> Message-ID: <452E9AE6.80808@redhat.com> Richard Allen Megginson (rmeggins) wrote: > Author: rmeggins > > Update of /cvs/dirsec/ldapserver/ldap/cm/newinst > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv5458 > > Modified Files: > ns-update > Log Message: > Bug(s) fixed: 185364 > Bug Description: Can't update scripts (e.g., start-slapd) in the instance directory > Reviewed by: ??? > Reviewed by: Noriko (Thanks!) > Fix Description: ns-update needs to run ds_create -r for each instance in the server root because the start-slapd et. al. scripts that it needs to recreate are per-instance. The install.inf passed in from setup only contains the information in the [General] and [admin] section. We need to supply the missing information for the [slapd] section to make both create_scripts() and reconfigure_instance() happy. > Platforms tested: RHEL4 > Flag Day: no > Doc impact: no > > > > Index: ns-update > =================================================================== > RCS file: /cvs/dirsec/ldapserver/ldap/cm/newinst/ns-update,v > retrieving revision 1.11 > retrieving revision 1.12 > diff -u -r1.11 -r1.12 > --- ns-update 23 Feb 2006 19:30:41 -0000 1.11 > +++ ns-update 12 Oct 2006 19:38:14 -0000 1.12 > @@ -46,6 +46,42 @@ > sroot=`echo $0 | sed s#/bin/slapd/admin/bin/.\*##g` > PERL=perl # just use perl from PATH > > +# run_ds_create "$sroot" "$dir" "$inffile" > +run_ds_create() > +{ > + sroot="$1" > + shift > + dir="$1" > + shift > + inffile="$1" > + > + # the inffile is incomplete - it needs the instance specific stuff > + dseldif=$sroot/$dir/config/dse.ldif > + port=`grep \^nsslapd-port: $dseldif | sed -e s/\^nsslapd-port:[\ \ ]*//` > + rootdn=`grep \^nsslapd-rootdn: $dseldif | sed -e s/\^nsslapd-rootdn:[\ \ ]*//` > + id=`echo $dir | sed -e s/^slapd-//` > + suffix="o=NetscapeRoot" > + > + realfile=/tmp/fds$$.inf > + cp $inffile $realfile > + echo "" >> $realfile > + echo "[slapd]" >> $realfile > + echo "ServerIdentifier= $id" >> $realfile > + echo "ServerPort= $port" >> $realfile > + echo "RootDN= $rootdn" >> $realfile > + # dummy password > + echo "RootDNPwd= password" >> $realfile > + echo "Suffix= $suffix" >> $realfile > + > + cwd=`pwd` > + cd `dirname $0` > + > + ./ds_create -r -f $realfile > + > + rm -f $realfile > + cd $cwd > +} > + > start_server() > { > NETSITE_ROOT=$1 > @@ -60,16 +96,26 @@ > cd $cwd > } > > +# get the inf file name > +seenfarg= > +inffile= > + > # if the -r flag is present, this means we're doing a > # reinstall or an upgrade, so restart the servers > -for arg in $* ; do > +for arg in "$@" ; do > if [ "$arg" = "-r" ]; then > reconfig=1 > fi > if [ "$arg" = "-S" ]; then > iDSISolaris=1 > fi > - > + if [ $seenfarg ]; then > + inffile="$arg" > + seenfarg= > + fi > + if [ "$arg" = "-f" ]; then > + seenfarg=1 > + fi > done > > extraflags= > @@ -114,6 +160,10 @@ > echo Starting $dir . . . > start_server $sroot $dir > echo "" > + > + # more reconfiguration > + run_ds_create "$sroot" "$dir" "$inffile" "$extraflags" "$@" > + > done > # fix any non-instance specific files - omit server instance argument > $PERL $sroot/bin/slapd/admin/bin/upgradeServer $sroot > @@ -124,19 +174,6 @@ > # we need to make sure the alias directory is owned by the server user/group > # in order for the server to be able to create the initial key/cert db files > > -# get the inf file name > -seenfarg= > -inffile= > -for arg in "$@" ; do > - if [ $seenfarg ] ; then > - inffile=$arg > - break > - fi > - if [ "$arg" = "-f" ] ; then > - seenfarg=1 > - fi > -done > - > if [ ! -f "$inffile" ] ; then > echo "WARNING: Could not read the setup info file $inffile" > else > @@ -149,7 +186,10 @@ > fi > > rc=0 > -./ds_create $* $extraflags > +# not reconfig - run ds_create as usual > +if test -z "$reconfig" ; then > + ./ds_create $* $extraflags > +fi > rc=$? > > # chown the cookie directory - bug 175098 > > -- > Fedora-directory-commits mailing list > Fedora-directory-commits at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-commits > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 12 21:09:54 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 12 Oct 2006 15:09:54 -0600 Subject: [Fedora-directory-devel] Please review: Bug 183903: Memory leak in ldbm_config.c:replace_ldbm_config_value Message-ID: <452EAF22.1070202@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183903 Bug(s) fixed: 183903 Bug Description: Memory leak in ldbm_config.c:replace_ldbm_config_value Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Just needed to call slapi_mods_done(&smods) after the call to slapi_modify_internal_pb(). This is the same as in the other places in the server that perform an internal modify operation. Platforms tested: RHEL4 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/bugzilla/show_bug.cgi?id=183903#c1 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 12 21:11:22 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 12 Oct 2006 15:11:22 -0600 Subject: [Fedora-directory-devel] Please review: Bug 185780: one byte memory leak in modify Message-ID: <452EAF7A.704@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185780 Bug(s) fixed: 185780 Bug Description: one byte memory leak in modify Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Just call ldap_memfree() with the mod->mod_type. This is safe to call with NULL. Platforms tested: RHEL4 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/bugzilla/show_bug.cgi?id=185780#c1 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 12 22:02:45 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 12 Oct 2006 16:02:45 -0600 Subject: [Fedora-directory-devel] Please review: Bug 204623: deleting attributes when changing password causes server crash Message-ID: <452EBB85.80906@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204623 Bug(s) fixed: 204623 Bug Description: deleting attributes when changing password causes server crash Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: From Michal: "The function mod2smod does not check for mod->mod_bvalues being NULL and tries to dereference it (modutil.c:370). This function happens to be called only by slapi_mods_get_{first,next}_smod(), which are in turn called only by check_trivial_words() in pw.c; this is why the crash appears only when checking password syntax." I added the same check for the mod_values case - even though the code says this should never be called, better to be safe than sorry. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138386 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Oct 13 02:05:04 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 12 Oct 2006 19:05:04 -0700 Subject: [Fedora-directory-devel] Commit: [Bug 208672] parameterizing the hardcoded paths (phase 2. db, log, lock, pid, cert, and instance dir) In-Reply-To: <200610130112.k9D1CONo005682@bugzilla.redhat.com> References: <200610130112.k9D1CONo005682@bugzilla.redhat.com> Message-ID: <452EF450.9010607@redhat.com> Summary: parameterizing the hardcoded paths (phase 2. db, log, lock, pid, cert, and instance dir) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208672 Hello, I've checked in lots of changes into CVS HEAD... This is the phase 2 work for parameterizing the hardcoded paths. Changes: 1) introduced these 3 new config attributes: nsslapd-lockdir, nsslapd-tmpdir, nsslapd-certdir, and eliminated: nsslapd-instancedir. 2) replaced the hardcoded paths with the corresponding attribute value in the server as well as in the create/remove instance codes. 3) moved snmp stats file to the nsslapd-tmpdir 4) moved the server instance dir to /lib/-ds/slapd- ------- Additional Comments From nhosoi at redhat.com 2006-10-12 21:12 EST ------- Created an attachment (id=138397) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138397&action=view) cvs commit message (for comment #18) Reviewed by Nathan (Thank you!!!) Checked in into HEAD. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From wpeng at innopath.com Sun Oct 15 04:17:37 2006 From: wpeng at innopath.com (Wallace Peng) Date: Sat, 14 Oct 2006 21:17:37 -0700 Subject: [Fedora-directory-devel] is there any one having a windows XP build ? Message-ID: Thanks a lot! Wallace -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Oct 16 15:34:49 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 16 Oct 2006 09:34:49 -0600 Subject: [Fedora-directory-devel] Please review: Bug 210916: Admin Server doesn't start on RHEL3 - libldap60.so + sasl Message-ID: <4533A699.9070609@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210916 Bug(s) fixed: 210916 Bug Description: Admin Server doesn't start on RHEL3 - libldap60.so + sasl Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Adding libldap60.so to the LD_PRELOAD solves the problem. Loading libldap60.so early forces the dynamic linker to find and resolve libsasl2.so. So I modified start-admin to do the LD_PRELOAD of libldap60. I also updated the patch file which is used when upgrading 1.0.2 to 1.0.3. Platforms tested: RHEL3 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138584 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Mon Oct 16 16:35:26 2006 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 16 Oct 2006 09:35:26 -0700 Subject: [Fedora-directory-devel] Please Review: (210736) Implement autotools build system (phase one) Message-ID: <4533B4CE.7040509@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210736 Bug(s) fixed: 210736 Bug Description: We need to make the Directory Server build system use GNU Autoconf and GNU Automake. The build system needs to support RHEL/FC systems, Solaris 9, and HP-UX IPF systems at a minimum for the first cut. Other platform support can be added in as needed. Implementing the new build system is going to be done in multiple phases. We need to leave the existing Makefiles around for a while until the new build system stabilizes. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The below bug attachments comprise the first phase of implementing the new build system. There are a number of files generated by autoconf that will need to be checked in as well, but they are all generated from the above attachments. There are also some modifications to some existing code that are needed for the new build-system to work. These changes are to modify buildnum.pl to just return the build number if the platform argument is not supplied. The new build system generated the build number at configure time and puts it in the generated Makefile instead of a buildnum.dat file. Also, the include line for ldap-agent.h was formatted for a system header file. This would cause the new build system to not locate it when compiling the SNMP subagent. The second phase will need to clean up some of the conditional defines as well as add configure options for things like an optimized build and 64-bit. All of this is possible with the current implementation by using CFLAGS, CXXFLAGS, etc. The second phase will also need to setup directories for doing a "make install". Platforms tested: RHEL4, Solaris 9, HP-UX 11.23 IA64 Flag Day: no Doc impact: no Makefile.am - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138468 configure.ac - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138469 db.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138470 icu.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138471 mozldap.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138472 netsnmp.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138473 nspr.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138474 nss.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138475 sasl.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138476 svrcore.m4 - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138477 diffs - https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138478 -------------- 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 Thu Oct 19 03:08:31 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 18 Oct 2006 21:08:31 -0600 Subject: [Fedora-directory-devel] Please review: Bug 211426: autotools: support dirsec packages, mozldap6, svrcore Message-ID: <4536EC2F.7090406@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211426 Bug(s) fixed: 211426 Bug Description: autotools: support dirsec packages, mozldap6, svrcore Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Look for the dirsec-nspr and dirsec-nss if nspr and nss are not found in pkg-config. Look for mozldap6 then mozldap in pkg-config. Look for svrcore-devel in pkg-config, then look for it in the system directories. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138851&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 19 16:36:19 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 19 Oct 2006 10:36:19 -0600 Subject: [Fedora-directory-devel] Redux: Please review: Bug 211426: autotools: support dirsec packages, mozldap6, svrcore Message-ID: <4537A983.8020905@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211426 Bug(s) fixed: 211426 Bug Description: autotools: support dirsec packages, mozldap6, svrcore Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Look for the dirsec-nspr and dirsec-nss if nspr and nss are not found in pkg-config. Look for mozldap6 then mozldap in pkg-config. Look for svrcore-devel in pkg-config, then look for it in the system directories. Nathan pointed out that we do not support mozldap v5.x anymore, so we should just look for mozldap6 with pkg-config. I also added an explicit check of the vendor version in the header file to make sure we are using 600 or greater. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138881&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Mon Oct 23 23:17:11 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 23 Oct 2006 16:17:11 -0700 Subject: [Fedora-directory-devel] Please review and comment: [Bug 210947] Processed: parameterizing the hardcoded paths (phase 3. installed binaries, change log, setup) In-Reply-To: <200610232238.k9NMc5t0029454@bugzilla.redhat.com> References: <200610232238.k9NMc5t0029454@bugzilla.redhat.com> Message-ID: <453D4D77.3080701@redhat.com> Summary: Processed: parameterizing the hardcoded paths (phase 3. installed binaries, change log, setup) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210947 Description of problem: Phase 3 of FHS support. This phase should cover all the leftovers. ------- Additional Comments From nhosoi at redhat.com 2006-10-23 18:38 EST ------- Created an attachment (id=139176) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139176&action=view) ldapserver files to be changed ------- Additional Comments From nhosoi at redhat.com 2006-10-23 19:02 EST ------- Created an attachment (id=139180) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139180&action=view) cvs diffs (ldapserver) Changes: 0) lots of makefiles are changed to adjust to the new FHS location and new library names, which are anyway replaced with makefiles autogenerated by autotools. So, they can be ignored. 1) Since ds_newinst.pl is also generated by autotools, I'd like to ask to make these changes to ds_newinst.am, too. With this change, ds_newinst program can get the prefix and branding info. Index: ldap/admin/src/ds_newinst.pl =================================================================== RCS file: /cvs/dirsec/ldapserver/ldap/admin/src/ds_newinst.pl,v retrieving revision 1.8 diff -t -w -U4 -r1.8 ds_newinst.pl --- ldap/admin/src/ds_newinst.pl 27 Sep 2006 23:40:50 -0000 1.8 +++ ldap/admin/src/ds_newinst.pl 23 Oct 2006 21:10:44 -0000 @@ -164,8 +164,9 @@ # next, construct a hash table with our arguments my %cgiargs = (); +my $brand_ds = "fedora-ds"; # the following items are always required addAndCheck(\%cgiargs, "sroot", \%table, "General", "ServerRoot"); addAndCheck(\%cgiargs, "servname", \%table, "General", "FullMachineName"); @@ -213,9 +214,14 @@ $cgiargs{user_ldap_url} = $cgiargs{ldap_url}; } if ($table{General}->{prefix}) { - $cgiargs{prefix} = $table{General}->{prefix}; + $prefix = $table{General}->{prefix}; +} +$cgiargs{prefix} = $prefix; + +if ($table{General}->{BrandDs}) { + $brand_ds = $table{General}->{BrandDs}; } # populate the DS with this file - the suffix in this file must # be the suffix specified in the suffix argument above @@ -229,9 +235,9 @@ my $sroot = $cgiargs{sroot}; my $rc = &cgiFake($sroot, $verbose, - $sroot . "/bin/slapd/admin/bin/ds_newinst", + $prefix . "/usr/lib/$brand_ds/ds_newinst", \%cgiargs); if (!$rc) { print "Success! Your new directory server instance was created\n"; As you could easily guess from this line: +$cgiargs{prefix} = $prefix; you can send these key-value pairs to ds_newinst: $cgiargs(config_dir) = ... === dse.ldif is put $cgiargs(schema_dir) = ... === schema files are put $cgiargs(lock_dir) = ... === lock file is put $cgiargs(log_dir) = ... === errors, access, and audit logs are put $cgiargs(run_dir) = ... === pid file is put $cgiargs(db_dir) = ... === db dir $cgiargs(bak_dir) = ... === back up dir $cgiargs(ldif_dir) = ... === default location db2ldif uses $cgiargs(tmp_dir) = ... === snmp puts the stat file here $cgiargs(cert_dir) = ... === key and cert db's are put 2) As for perl task scripts, would it be okay to set PATH and LD_LIBRARY_PATH like this and run the command? It could call LDAP C SDK tools as well as libdb tools. Index: ldap/admin/src/scripts/template-db2bak.pl =================================================================== RCS file: /cvs/dirsec/ldapserver/ldap/admin/src/scripts/template-db2bak.pl,v retrieving revision 1.5 diff -t -w -U4 -r1.5 template-db2bak.pl --- ldap/admin/src/scripts/template-db2bak.pl 13 Oct 2006 01:06:21 -0000 1.5 +++ ldap/admin/src/scripts/template-db2bak.pl 23 Oct 2006 21:10:44 -0000 @@ -114,8 +114,10 @@ $nsdbtype = "nsDatabaseType: $dbtype\n"; $entry = "${dn}${misc}${cn}${nsarchivedir}${nsdbtype}"; $vstr = ""; if ($verbose != 0) { $vstr = "-v"; } -chdir("$prefix{{SEP}}shared{{SEP}}bin"); -open(FOO, "| $prefix{{SEP}}shared{{SEP}}bin{{SEP}}ldapmodify $vstr -h {{SERVER-NAME}} -p {{SERVER-PORT}} -D \"$rootdn\" -w \"$passwd\" -a" ); +$ENV{'PATH'} = '$prefix{{SEP}}usr{{SEP}}lib:{{SEP}}usr{{SEP}}lib{{SEP}}mozldap6'; +$ENV{'LD_LIBRARY_PATH'} = '$prefix{{SEP}}usr{{SEP}}lib:{{SEP}}usr{{SEP}}lib{{SEP}}dirsec'; +$ENV{'SHLIB_PATH'} = '$prefix{{SEP}}usr{{SEP}}lib:{{SEP}}usr{{SEP}}lib{{SEP}}dirsec'; +open(FOO, "| ldapmodify $vstr -h {{SERVER-NAME}} -p {{SERVER-PORT}} -D \"$rootdn\" -w \"$passwd\" -a" ); print(FOO "$entry"); close(FOO); -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Oct 25 18:23:05 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 25 Oct 2006 11:23:05 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: References: Message-ID: <453FAB89.6010202@redhat.com> Summary: Use autoconf to generate task perl script templates https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098 Summary: Use autoconf to generate task perl script templates Product: Fedora Directory Server Version: 1.0.2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Command Line Utilities AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ohegarty at redhat.com CC: ohegarty at redhat.com Estimated Hours: 0.0 Description of problem: Instead of hardcoding the paths of mozldap, libdb, dirsec libs and tools, set them via autoconf. ------- Additional Comments From nhosoi at redhat.com 2006-10-25 14:08 EST ------- Created an attachment (id=139372) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139372&action=view) cvs diffs configure.ac m4/{db.m4,mozldap.m4} Files: configure.ac m4/db.m4 m4/mozldap.m4 Changes: 1) added template files to AC_CONFIG_FILES list 2) added db_bindir and ldapsdk_bindir to pass their tools path to the template files. The paths are hardcoded for now. Notes: 1. The templates' in files are being added in the next attachment. 2. The template files are not "installed" now. ------- Additional Comments From nhosoi at redhat.com 2006-10-25 14:19 EST ------- Created an attachment (id=139374) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139374&action=view) diffs between template-*.pl and template-*.pl.in files Files: template-bak2db.pl.in template-ns-activate.pl.in template-cl-dump.pl.in* template-ns-inactivate.pl.in template-db2bak.pl.in template-ns-newpwpolicy.pl.in* template-db2index.pl.in template-repl-monitor-cgi.pl.in* template-db2ldif.pl.in template-repl-monitor.pl.in* template-ldif2db.pl.in template-verify-db.pl.in template-ns-accountstatus.pl.in Description: Since only the paths are replaced by autoconf, attaching just the diff output. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Oct 25 22:43:08 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 25 Oct 2006 15:43:08 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> Message-ID: <453FE87C.6090907@redhat.com> Summary: Use autoconf to generate task perl script templates https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098 Problem Description: Notes in Comment#1 2. The template files are not "installed" now. With this change, the perl template files are installed in $prefix/etc/brand-ds/script-templates ------- Additional Comments From nhosoi at redhat.com 2006-10-25 18:34 EST ------- Created an attachment (id=139419) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=view) cvs diff configure.ac Makefile.am Files: configure.ac MAkefile.am Changes; 1) added task perl script templates to "install" at @sysconfdir@@scripttemplatedir@ to Makefile.am 2) added scripttemplatedir = /fedora-ds/script-templates to configure.ac Question: changing these files, Makefile.in and configure are also updated. Am I supposed to check them in? M Makefile.am M Makefile.in M configure M configure.ac What |Removed |Added ---------------------------------------------------------------------------- devel_whiteboard| |review.comment#7? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Oct 26 01:02:12 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 26 Oct 2006 11:02:12 +1000 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <453FE87C.6090907@redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> Message-ID: <1161824532.9692.44.camel@amy.samba4.abartlet.net> On Wed, 2006-10-25 at 15:43 -0700, Noriko Hosoi wrote: > Summary: Use autoconf to generate task perl script templates > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098 > > Problem Description: > Notes in Comment#1 > 2. The template files are not "installed" now. > > With this change, the perl template files are installed in $prefix/etc/brand-ds/script-templates > > ------- Additional Comments From nhosoi at redhat.com 2006-10-25 18:34 EST ------- > Created an attachment (id=139419) > --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=view) > cvs diff configure.ac Makefile.am > > Files: > configure.ac > MAkefile.am > > Changes; > 1) added task perl script templates to "install" at > @sysconfdir@@scripttemplatedir@ to Makefile.am > 2) added scripttemplatedir = /fedora-ds/script-templates to configure.ac > > Question: changing these files, Makefile.in and configure are also updated. Am > I supposed to check them in? > M Makefile.am > M Makefile.in > M configure > M configure.ac This depends on the project, and I don't know the rules here. In Samba (just as a note, for comparison), we did commit these generated files our to CVS for many years, but it just created a lot of noise on commit, as different developers had slightly different tools, which would rearrange the files rather often. Our current policy is to generate these files for release tarballs, and for our 'unpacked' tree on samba.org (current SVN checked out). 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 prowley at redhat.com Thu Oct 26 01:14:07 2006 From: prowley at redhat.com (Pete Rowley) Date: Wed, 25 Oct 2006 18:14:07 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <1161824532.9692.44.camel@amy.samba4.abartlet.net> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> Message-ID: <45400BDF.7090307@redhat.com> Andrew Bartlett wrote: > On Wed, 2006-10-25 at 15:43 -0700, Noriko Hosoi wrote: > >> Summary: Use autoconf to generate task perl script templates >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098 >> >> Problem Description: >> Notes in Comment#1 >> 2. The template files are not "installed" now. >> >> With this change, the perl template files are installed in $prefix/etc/brand-ds/script-templates >> >> ------- Additional Comments From nhosoi at redhat.com 2006-10-25 18:34 EST ------- >> Created an attachment (id=139419) >> --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=view) >> cvs diff configure.ac Makefile.am >> >> Files: >> configure.ac >> MAkefile.am >> >> Changes; >> 1) added task perl script templates to "install" at >> @sysconfdir@@scripttemplatedir@ to Makefile.am >> 2) added scripttemplatedir = /fedora-ds/script-templates to configure.ac >> >> Question: changing these files, Makefile.in and configure are also updated. Am >> I supposed to check them in? >> M Makefile.am >> M Makefile.in >> M configure >> M configure.ac >> > > This depends on the project, and I don't know the rules here. > > In Samba (just as a note, for comparison), we did commit these generated > files our to CVS for many years, but it just created a lot of noise on > commit, as different developers had slightly different tools, which > would rearrange the files rather often. > > Our current policy is to generate these files for release tarballs, and > for our 'unpacked' tree on samba.org (current SVN checked out). > OTOH they are required in order to do: cvs co ./configure make -- Pete -------------- 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 nhosoi at redhat.com Thu Oct 26 01:35:13 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 25 Oct 2006 18:35:13 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <45400BDF.7090307@redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> <45400BDF.7090307@redhat.com> Message-ID: <454010D1.6070202@redhat.com> Thank you for your comments, Andrew and Pete! Nathan told me that we should check them in since we should not expect customers to run autoconf/automake. But we are skipping to put the diffs to the review request. I think the rule looks similar to the samba rule and am going to follow it... Thanks! --noriko Pete Rowley wrote: > Andrew Bartlett wrote: > >> On Wed, 2006-10-25 at 15:43 -0700, Noriko Hosoi wrote: >> >> >>> Summary: Use autoconf to generate task perl script templates >>> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098 >>> >>> Problem Description: >>> Notes in Comment#1 >>> 2. The template files are not "installed" now. >>> >>> With this change, the perl template files are installed in >>> $prefix/etc/brand-ds/script-templates >>> >>> ------- Additional Comments From nhosoi at redhat.com 2006-10-25 >>> 18:34 EST ------- >>> Created an attachment (id=139419) >>> --> >>> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=view) >>> >>> cvs diff configure.ac Makefile.am >>> >>> Files: >>> configure.ac >>> MAkefile.am >>> >>> Changes; >>> 1) added task perl script templates to "install" at >>> @sysconfdir@@scripttemplatedir@ to Makefile.am >>> 2) added scripttemplatedir = /fedora-ds/script-templates to >>> configure.ac >>> >>> Question: changing these files, Makefile.in and configure are also >>> updated. Am >>> I supposed to check them in? >>> M Makefile.am >>> M Makefile.in >>> M configure >>> M configure.ac >>> >> >> >> This depends on the project, and I don't know the rules here. >> In Samba (just as a note, for comparison), we did commit these generated >> files our to CVS for many years, but it just created a lot of noise on >> commit, as different developers had slightly different tools, which >> would rearrange the files rather often. >> >> Our current policy is to generate these files for release tarballs, and >> for our 'unpacked' tree on samba.org (current SVN checked out). >> > > OTOH they are required in order to do: > > cvs co > ./configure > make > > >------------------------------------------------------------------------ > >-- >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: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Oct 26 02:13:27 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 26 Oct 2006 12:13:27 +1000 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <45400BDF.7090307@redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> <45400BDF.7090307@redhat.com> Message-ID: <1161828807.9692.63.camel@amy.samba4.abartlet.net> On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote: > Andrew Bartlett wrote: > > Our current policy is to generate these files for release tarballs, and > > for our 'unpacked' tree on samba.org (current SVN checked out). > > > OTOH they are required in order to do: > > cvs co > ./configure > make Yeah, projects typically end up with an ./autogen.sh to make the right innovation of the configure generation tool. 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 rmeggins at redhat.com Thu Oct 26 02:30:29 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 25 Oct 2006 20:30:29 -0600 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <1161828807.9692.63.camel@amy.samba4.abartlet.net> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> <45400BDF.7090307@redhat.com> <1161828807.9692.63.camel@amy.samba4.abartlet.net> Message-ID: <45401DC5.2040302@redhat.com> Andrew Bartlett wrote: > On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote: > >> Andrew Bartlett wrote: >> >>> Our current policy is to generate these files for release tarballs, and >>> for our 'unpacked' tree on samba.org (current SVN checked out). >>> >>> >> OTOH they are required in order to do: >> >> cvs co >> ./configure >> make >> > > Yeah, projects typically end up with an ./autogen.sh to make the right > innovation of the configure generation tool. > I've found that using autoreconf usually does the right thing. When I change configure.ac/in or Makefile.am or an .m4 file, I always run autoreconf -vfi -v, --verbose verbosely report processing -f, --force consider all files obsolete -i, --install copy missing auxiliary files It takes a little longer, but I almost never have conflict or timestamp problems. Plus, it's part of the standard autotools package, and it is the way the autoconf/automake manuals recommend rebuilding the autotool files. For some projects, this won't work (e.g. for mozldap, you have to just use autoconf-2.13, not autoreconf or autoreconf-2.13). > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > 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: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Thu Oct 26 02:45:33 2006 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 25 Oct 2006 19:45:33 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <45401DC5.2040302@redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> <45400BDF.7090307@redhat.com> <1161828807.9692.63.camel@amy.samba4.abartlet.net> <45401DC5.2040302@redhat.com> Message-ID: <4540214D.2060901@redhat.com> Richard Megginson wrote: > Andrew Bartlett wrote: >> On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote: >> >>> Andrew Bartlett wrote: >>> >>>> Our current policy is to generate these files for release tarballs, >>>> and >>>> for our 'unpacked' tree on samba.org (current SVN checked out). >>>> >>> OTOH they are required in order to do: >>> >>> cvs co >>> ./configure >>> make >>> >> >> Yeah, projects typically end up with an ./autogen.sh to make the right >> innovation of the configure generation tool. >> > I've found that using autoreconf usually does the right thing. When I > change configure.ac/in or Makefile.am or an .m4 file, I always run > autoreconf -vfi > -v, --verbose verbosely report processing > -f, --force consider all files obsolete > -i, --install copy missing auxiliary files > It takes a little longer, but I almost never have conflict or > timestamp problems. Plus, it's part of the standard autotools > package, and it is the way the autoconf/automake manuals recommend > rebuilding the autotool files. > For some projects, this won't work (e.g. for mozldap, you have to just > use autoconf-2.13, not autoreconf or autoreconf-2.13). As I just very recently found out, we also need a very specific version of libtool (1.5.22) to generate ltmain.sh if we want to be able to build a 64-bit Directory Server on Solaris. Running "autoreconf -fvi" will generate a new ltmain.sh that may be a version that we don't want to check in if we expect to be able to immediately run "configure; make install" after checking out the code. -NGK >> Andrew Bartlett >> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ------------------------------------------------------------------------ > > -- > 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: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Oct 26 12:58:46 2006 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Oct 2006 08:58:46 -0400 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <4540214D.2060901@redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> <45400BDF.7090307@redhat.com> <1161828807.9692.63.camel@amy.samba4.abartlet.net> <45401DC5.2040302@redhat.com> <4540214D.2060901@redhat.com> Message-ID: <4540B106.7020505@redhat.com> Nathan Kinder wrote: > Richard Megginson wrote: >> Andrew Bartlett wrote: >>> On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote: >>> >>>> Andrew Bartlett wrote: >>>> >>>>> Our current policy is to generate these files for release tarballs, >>>>> and >>>>> for our 'unpacked' tree on samba.org (current SVN checked out). >>>>> >>>> OTOH they are required in order to do: >>>> >>>> cvs co >>>> ./configure >>>> make >>>> >>> >>> Yeah, projects typically end up with an ./autogen.sh to make the right >>> innovation of the configure generation tool. >>> >> I've found that using autoreconf usually does the right thing. When I >> change configure.ac/in or Makefile.am or an .m4 file, I always run >> autoreconf -vfi >> -v, --verbose verbosely report processing >> -f, --force consider all files obsolete >> -i, --install copy missing auxiliary files >> It takes a little longer, but I almost never have conflict or >> timestamp problems. Plus, it's part of the standard autotools >> package, and it is the way the autoconf/automake manuals recommend >> rebuilding the autotool files. >> For some projects, this won't work (e.g. for mozldap, you have to just >> use autoconf-2.13, not autoreconf or autoreconf-2.13). > As I just very recently found out, we also need a very specific version > of libtool (1.5.22) to generate ltmain.sh if we want to be able to build > a 64-bit Directory Server on Solaris. Running "autoreconf -fvi" will > generate a new ltmain.sh that may be a version that we don't want to > check in if we expect to be able to immediately run "configure; make > install" after checking out the code. > > -NGK The real pain is when not all of the files have changed and you check in only those that did. This can cause an unwanted auto* rebuild. I've taken to checking everything in at once whenever one thing changes with: cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure This preserves the proper timestamp/dependency order (at least for me). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 26 14:09:44 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 26 Oct 2006 08:09:44 -0600 Subject: [Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <4540B106.7020505@redhat.com> References: <200610252234.k9PMYn7D019700@bugzilla.redhat.com> <453FE87C.6090907@redhat.com> <1161824532.9692.44.camel@amy.samba4.abartlet.net> <45400BDF.7090307@redhat.com> <1161828807.9692.63.camel@amy.samba4.abartlet.net> <45401DC5.2040302@redhat.com> <4540214D.2060901@redhat.com> <4540B106.7020505@redhat.com> Message-ID: <4540C1A8.8010705@redhat.com> Rob Crittenden wrote: > Nathan Kinder wrote: >> Richard Megginson wrote: >>> Andrew Bartlett wrote: >>>> On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote: >>>> >>>>> Andrew Bartlett wrote: >>>>> >>>>>> Our current policy is to generate these files for release >>>>>> tarballs, and >>>>>> for our 'unpacked' tree on samba.org (current SVN checked out). >>>>>> >>>>> OTOH they are required in order to do: >>>>> >>>>> cvs co >>>>> ./configure >>>>> make >>>>> >>>> >>>> Yeah, projects typically end up with an ./autogen.sh to make the right >>>> innovation of the configure generation tool. >>>> >>> I've found that using autoreconf usually does the right thing. When >>> I change configure.ac/in or Makefile.am or an .m4 file, I always run >>> autoreconf -vfi >>> -v, --verbose verbosely report processing >>> -f, --force consider all files obsolete >>> -i, --install copy missing auxiliary files >>> It takes a little longer, but I almost never have conflict or >>> timestamp problems. Plus, it's part of the standard autotools >>> package, and it is the way the autoconf/automake manuals recommend >>> rebuilding the autotool files. >>> For some projects, this won't work (e.g. for mozldap, you have to >>> just use autoconf-2.13, not autoreconf or autoreconf-2.13). >> As I just very recently found out, we also need a very specific >> version of libtool (1.5.22) to generate ltmain.sh if we want to be >> able to build a 64-bit Directory Server on Solaris. Running >> "autoreconf -fvi" will generate a new ltmain.sh that may be a version >> that we don't want to check in if we expect to be able to immediately >> run "configure; make install" after checking out the code. >> >> -NGK > > The real pain is when not all of the files have changed and you check > in only those that did. This can cause an unwanted auto* rebuild. > > I've taken to checking everything in at once whenever one thing > changes with: > > cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure > > This preserves the proper timestamp/dependency order (at least for me). If autoreconf doesn't work for directory server, do we need to create an autogen.sh script that "does the right thing"? I would rather not, but if that is the only way to preserve the correct version of ltmain.sh, then we need to do it. For example, we won't be able to use libtool on RHEL4 (with the standard RH updates anyway) because the bundled version of libtool is 1.5.6. However, Fedora Core 5 (and probably RHEL5) are ok because they use 1.5.22. I fear this may not be the only problem with autotool compatability - we also had a problem with hpux 11.23 ia64. So, some options: 1) Only use autoreconf, and only run it on systems that use recent versions of autotools (e.g. fc5) - do not allow the use of autotools on RHEL4 or other less recent platforms. 2) Create an autogen.sh that first looks at the versions of the tools on the system and bails out if it finds an incompatible version - note that we would still have to run it on a modern system in order to actually update the autoconf files 2a) Have autogen.sh "patch" ltmain.sh when run on less recent systems, to allow us to use it on RHEL4 etc. 3) Make ltmain.sh (and possibly other files) somehow read-only with respect to autoreconf > > rob > ------------------------------------------------------------------------ > > -- > 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: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From hyc at symas.com Thu Oct 26 16:20:39 2006 From: hyc at symas.com (Howard Chu) Date: Thu, 26 Oct 2006 09:20:39 -0700 Subject: [Fedora-directory-devel] Re: Fedora-directory-devel Digest, Vol 16, Issue 14 In-Reply-To: <20061026160031.BDDE573B52@hormel.redhat.com> References: <20061026160031.BDDE573B52@hormel.redhat.com> Message-ID: <4540E057.2050508@symas.com> Welcome to autotools hell... fedora-directory-devel-request at redhat.com wrote: >> The real pain is when not all of the files have changed and you check >> in only those that did. This can cause an unwanted auto* rebuild. >> >> I've taken to checking everything in at once whenever one thing >> changes with: >> >> cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure >> >> This preserves the proper timestamp/dependency order (at least for me). First: use a recent automake (1.9.x) that supports the AM_MAINTAINER_MODE macro, and use that in your configure.ac file. This will turn off the automatic dependency checking/regeneration of the Makefile/configure/etc scripts unless you explicitly ask for them (using configure --enable-maintainer-mode). As a general rule, you don't want maintainer mode enabled. It was stupid of them to make it the default behavior but at least it's possible to turn it off now. Personally I disable as much of this cruft as possible, because even as a source tree maintainer it only slows me down. (OpenLDAP uses hand-written Makefile.in and avoids automake because older versions of automake were just too painful to deal with.) In source trees that we import from other projects (Heimdal and Cyrus SASL being the prime offenders here) I always doctor up the Makefile.in's to comment out the autoregen dependencies before importing them. There's no reliable way to make sure the datestamps come out of the CVS repository intact. A slight network delay during a checkout will cause some files to be newer than expected, thus causing an unnecessary regen cycle. So in short: commit everything up to the configure script, so that arbitrary people can do a checkout / configure / make. Only a very small number of people should ever be regenerating and committing the other auto* files, so remove the default rules that cause them to be regenerated automatically. (I.e., use AM_MAINTAINER_MODE.) As a further refinement, I added these rules to OpenLDAP's configure.in to speed up libtool generation: dnl Disable libtool 1.5 support for languages we don't use define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl define([AC_LIBTOOL_LANG_GCJ_CONFIG], [:])dnl Of course if you're actually using C++ you'll have to let that run as usual. But it saves a noticable amount of time on slow build machines to bypass checks for languages we don't need. > If autoreconf doesn't work for directory server, do we need to create an > autogen.sh script that "does the right thing"? I would rather not, but > if that is the only way to preserve the correct version of ltmain.sh, > then we need to do it. For example, we won't be able to use libtool on > RHEL4 (with the standard RH updates anyway) because the bundled version > of libtool is 1.5.6. However, Fedora Core 5 (and probably RHEL5) are ok > because they use 1.5.22. I fear this may not be the only problem with > autotool compatability - we also had a problem with hpux 11.23 ia64. > > So, some options: > 1) Only use autoreconf, and only run it on systems that use recent > versions of autotools (e.g. fc5) - do not allow the use of autotools on > RHEL4 or other less recent platforms. Probably will cause more problems down the road. > 2) Create an autogen.sh that first looks at the versions of the tools on > the system and bails out if it finds an incompatible version - note that > we would still have to run it on a modern system in order to actually > update the autoconf files This is probably the most workable idea, and it's not a major hardship. > 2a) Have autogen.sh "patch" ltmain.sh when run on less recent systems, > to allow us to use it on RHEL4 etc. > 3) Make ltmain.sh (and possibly other files) somehow read-only with > respect to autoreconf >> rob -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ From hyc at symas.com Thu Oct 26 19:15:58 2006 From: hyc at symas.com (Howard Chu) Date: Thu, 26 Oct 2006 12:15:58 -0700 Subject: [Fedora-directory-devel] Re: Please review: [Bug 212098] Use autoconf to generate task perl script templates In-Reply-To: <4540E057.2050508@symas.com> References: <20061026160031.BDDE573B52@hormel.redhat.com> <4540E057.2050508@symas.com> Message-ID: <4541096E.9010606@symas.com> Howard Chu wrote: > Welcome to autotools hell... > > fedora-directory-devel-request at redhat.com wrote: > >>> The real pain is when not all of the files have changed and you check >>> in only those that did. This can cause an unwanted auto* rebuild. >>> >>> I've taken to checking everything in at once whenever one thing >>> changes with: >>> >>> cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure >>> >>> This preserves the proper timestamp/dependency order (at least for me). > > First: use a recent automake (1.9.x) that supports the > AM_MAINTAINER_MODE macro, and use that in your configure.ac file. This > will turn off the automatic dependency checking/regeneration of the > Makefile/configure/etc scripts unless you explicitly ask for them (using > configure --enable-maintainer-mode). As a general rule, you don't want > maintainer mode enabled. It was stupid of them to make it the default > behavior but at least it's possible to turn it off now. One more note - it will make your lives easier if you standardize on a single version of each tool, so that when you check in newly generated files the diffs will be small and meaningful. Otherwise you get a lot of noise, as Andrew already pointed out. In the past we had things set up so that only a single maintainer was permitted to regenerate and check in configure script and associated files, to avoid the issue of having many tool versions in use. Also there were fixes in our blessed tool versions that the upstream maintainers hadn't rolled out yet, so we had to keep tarballs of the specific tools available for download as well. I think we still have a minor patch in our autoconf tool that the upstream guys haven't adopted yet - redirecting stderr from the conftest programs into the logfile instead of /dev/null (which stock autoconf does), so that it's actually possible to diagnose why a config test fails. It never fails to amaze me how incredibly un-useful these tools are out of the box, and how long it takes to get them fixed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ From Nathanael.Huddleson at acxiom.com Mon Oct 30 21:26:03 2006 From: Nathanael.Huddleson at acxiom.com (Huddleson Nathanael - nhuddl) Date: Mon, 30 Oct 2006 15:26:03 -0600 Subject: [Fedora-directory-devel] preop modify plugin woes Message-ID: I'm working on a preop modify plugin to add additional password strength tests. As I have been working through it, I had many troubles until I decided to print the password to the logs. It seems that the password is being encoded into password storage hash before my pre-op function gains access to it. Is there a way to define a function that is exectuted before the hash is applied, or maybe a way to retrieve the un-hashed password in the modify function? Thanks! Nathanael Huddleson Software Developer Nathanael.Huddleson at acxiom.com ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Oct 30 22:40:51 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 30 Oct 2006 15:40:51 -0700 Subject: [Fedora-directory-devel] preop modify plugin woes In-Reply-To: References: Message-ID: <45467F73.9050709@redhat.com> Huddleson Nathanael - nhuddl wrote: > I'm working on a preop modify plugin to add additional password > strength tests. As I have been working through it, I had many > troubles until I decided to print the password to the logs. It seems > that the password is being encoded into password storage hash before > my pre-op function gains access to it. Is there a way to define a > function that is exectuted before the hash is applied, or maybe a way > to retrieve the un-hashed password in the modify function? /* Used to make unhashed passwords available to plugins. */ #define PSEUDO_ATTR_UNHASHEDUSERPASSWORD "unhashed#user#password" See - http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/slapd/slap.h#287 However, slap.h is a "private" interface - we should probably move this to slapi-plugin.h > > Thanks! > > Nathanael Huddleson > Software Developer > Nathanael.Huddleson at acxiom.com > > ************************************************************************* > The information contained in this communication is confidential, is > intended only for the use of the recipient named above, and may be > legally privileged. > > If the reader of this message is not the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. > > If you have received this communication in error, please resend this > communication to the sender and delete the original message or any copy > of it from your computer system. > > Thank you. > ************************************************************************* > > ------------------------------------------------------------------------ > > -- > 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: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Oct 31 00:30:54 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 30 Oct 2006 16:30:54 -0800 Subject: [Fedora-directory-devel] Re: [Bug 199923] subtree search fails to find items under a db containing special characters In-Reply-To: <200610302147.k9ULlLtD031093@bugzilla.redhat.com> References: <200610302147.k9ULlLtD031093@bugzilla.redhat.com> Message-ID: <4546993E.1050609@redhat.com> Summary: subtree search fails to find items under a db containing special characters https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199923 Bug Description: When add or import an entry which dn contains '\\', subtree search does not return the entry even though the entry satisfies the search criteria. ------- Additional Comments From nhosoi at redhat.com 2006-10-30 16:47 EST ------- Created an attachment (id=139778) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139778&action=view) sample ldif step to reproduce: 1) stop slapd 2) import the sample ldif file 3) run subtree search with the filter "(ou=*)" and the attribute list "dn" expected result: search result dn: ou=Accounting, dc=example,dc=com actual result: search result dn: ou=Accounting, dc=example,dc=com dn: ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com dn: uid=TVradmin0, ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=entry,dc=com ------- Additional Comments From nhosoi at redhat.com 2006-10-30 19:24 EST ------- Created an attachment (id=139786) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139786&action=view) cvs diffs (ldapserver) Files: ldap/servers/slapd/back-ldbm/backentry.c ldap/servers/slapd/back-ldbm/import-threads.c \ ldap/servers/slapd/back-ldbm/ldbm_add.c \ ldap/servers/slapd/back-ldbm/proto-back-ldbm.h Bug description: The directory server internally normalizes the dn and uses the normalized dn to compare. In some cases, the server was normalizing the dn more than once. Normally, the normalized string is identical to the renormalized dn. { i.e., normalized_dn == normalize(normalize_dn) } The problem is, if the dn contains '\\' (not just the escape character, but it contains some real backslash characters: dn: ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com), the string is transformed to the one which is not considered to be the same as the original. (the normalization is done in the function substr_dn_normalize in slapd/dn.c; if you are interested in, the function has a detailed comment). Changes: Avoid re-normalizing an already normalized dn. It should be better from the performance point of view, as well. Note: When running ldapsearch having such attribute values containing '"' in it, we should use single quote to quote the string. Otherwise, the command line interface consumes the backslash before '"' and mismatched string is passed to the server and returns "no such object". $ dapsearch -p -D "cn=Directory Manager" -w -b 'ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com' '(ou=\#\,\+\"\\\>:\=\<\<\>\;/)' version: 1 dn: ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: \#\,\+\"\\\>:\=\<\<\>\;/ ou: #,+"\>:=<<>;/ $ ldapsearch -p -D "cn=Directory Manager" -w -b "ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com" "(ou=\#\,\+\"\\\>:\=\<\<\>\;/)" ldap_search: No such object -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Oct 31 00:33:26 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 30 Oct 2006 16:33:26 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 199923] subtree search fails to find items under a db containing special characters In-Reply-To: <4546993E.1050609@redhat.com> References: <200610302147.k9ULlLtD031093@bugzilla.redhat.com> <4546993E.1050609@redhat.com> Message-ID: <454699D6.6000509@redhat.com> Sorry, I forgot to add the keyword "Please review" to the subject... :p > Summary: subtree search fails to find items under a db containing > special characters > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199923 > > Bug Description: > When add or import an entry which dn contains '\\', subtree search > does not return the entry even though the entry satisfies the search > criteria. > > ------- Additional Comments From nhosoi at redhat.com 2006-10-30 16:47 > EST ------- > Created an attachment (id=139778) > --> > (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139778&action=view) > > sample ldif > > step to reproduce: > 1) stop slapd > 2) import the sample ldif file > 3) run subtree search with the filter "(ou=*)" and the attribute list > "dn" > > expected result: > search result > dn: ou=Accounting, dc=example,dc=com > > actual result: > search result > dn: ou=Accounting, dc=example,dc=com > dn: ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com > dn: uid=TVradmin0, ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=entry,dc=com > > ------- Additional Comments From nhosoi at redhat.com 2006-10-30 19:24 > EST ------- > Created an attachment (id=139786) > --> > (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139786&action=view) > > cvs diffs (ldapserver) > > Files: > ldap/servers/slapd/back-ldbm/backentry.c > ldap/servers/slapd/back-ldbm/import-threads.c \ > ldap/servers/slapd/back-ldbm/ldbm_add.c \ > ldap/servers/slapd/back-ldbm/proto-back-ldbm.h > > Bug description: > The directory server internally normalizes the dn and uses the > normalized dn to > compare. In some cases, the server was normalizing the dn more than > once. Normally, the normalized string is identical to the renormalized > dn. { i.e., > normalized_dn == normalize(normalize_dn) } The problem is, if the dn > contains > '\\' (not just the escape character, but it contains some real backslash > characters: dn: ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com), the > string is > transformed to the one which is not considered to be the same as the > original. (the normalization is done in the function > substr_dn_normalize in slapd/dn.c; > if you are interested in, the function has a detailed comment). > > Changes: > Avoid re-normalizing an already normalized dn. It should be better > from the > performance point of view, as well. > > Note: > When running ldapsearch having such attribute values containing '"' in > it, we > should use single quote to quote the string. Otherwise, the command line > interface consumes the backslash before '"' and mismatched string is > passed to > the server and returns "no such object". > $ dapsearch -p -D "cn=Directory Manager" -w -b > 'ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com' > '(ou=\#\,\+\"\\\>:\=\<\<\>\;/)' > version: 1 > dn: ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com > objectClass: organizationalUnit > objectClass: top > ou: \#\,\+\"\\\>:\=\<\<\>\;/ > ou: #,+"\>:=<<>;/ > > $ ldapsearch -p -D "cn=Directory Manager" -w -b > "ou=\#\,\+\"\\\>:\=\<\<\>\;/, dc=example,dc=com" > "(ou=\#\,\+\"\\\>:\=\<\<\>\;/)" > ldap_search: No such object -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 31 16:53:04 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 31 Oct 2006 09:53:04 -0700 Subject: [Fedora-directory-devel] Announcing Fedora Directory Server 1.0.3 Message-ID: <45477F70.6070505@redhat.com> Fedora Directory Server 1.0.3 is released! This release is primarily a bug fix release. * The password extended operation (ldappasswd) can now generate a new password * Bug fixes - follow this link (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208654) to see the bugzilla report * Upgraded components - NSPR 4.6.3, NSS 3.11.3, LDAPCSDK 6.0.0 Release Notes: http://directory.fedora.redhat.com/wiki/Release_Notes Download: http://directory.fedora.redhat.com/wiki/Download Home Page: http://directory.fedora.redhat.com/wiki/Main_Page -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From Nathanael.Huddleson at acxiom.com Tue Oct 31 21:45:00 2006 From: Nathanael.Huddleson at acxiom.com (Huddleson Nathanael - nhuddl) Date: Tue, 31 Oct 2006 15:45:00 -0600 Subject: [Fedora-directory-devel] preop modify plugin woes Message-ID: Richard Megginson wrote: >/* Used to make unhashed passwords available to plugins. */ >#define PSEUDO_ATTR_UNHASHEDUSERPASSWORD "unhashed#user#password" > >See - >http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/ slapd/slap.h#287 Thanks, that worked! Nathanael Huddleson Nathanael.Huddleson at acxiom.com ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* From rmeggins at redhat.com Tue Oct 31 23:29:01 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 31 Oct 2006 16:29:01 -0700 Subject: [Fedora-directory-devel] Please review: Bug 213352: autotools: support redhat/fedora rpmbuild %configure and %makeinstall Message-ID: <4547DC3D.4000102@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213352 Bug(s) fixed: 213352 Bug Description: autotools: support redhat/fedora rpmbuild %configure and %makeinstall Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The standard way to do an rpmbuild on fedora/redhat is to use the %configure macro in the %prep section of the spec file and the %makeinstall macro in the %install section. These set all of the bindir, libdir, datadir, sysconfdir, etc. paths used by the application. %configure sets them to their "real" runtime locations e.g. /usr/lib, and %makeinstall sets them to their paths used for rpm packaging e.g. /var/tmp/fedora-ds-foo-bar-baz/usr/lib. There were a few places in our autotools files where we were running afoul of this. Another thing is that configure defines bindir etc. as literally '${exec_prefix}/bin' so that the real value doesn't get expanded until make or make install time. This means that we cannot create scripts from templates in configure, we have to do that in make. So this adds a sed command to Makefile.am in order to do all of the script and config file path replacement at make time. Since we do the subst this way, whatever $prefix is set during make will be incorporated into the value of $bindir etc. so we can omit directly referencing @prefix@ in the template files. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139919&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: