From rmeggins at redhat.com Mon Feb 5 23:49:06 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 05 Feb 2007 16:49:06 -0700 Subject: [Fedora-directory-devel] Please review: Bug 227452: Solaris build: Need to add other libs for autotool build Message-ID: <45C7C272.1060706@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227452 Resolves: bug 227452 Bug Description: Solaris build: Need to add other libs for autotool build Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The AC_CHECK_LIB test for db_create needs -lnsl because libdb links with it on Solaris. Other executables require -lnsl, -lsocket, and -ldl. The strategy is to put these in the platform specific section in configure.ac so they can be exported to the Makefile. Then we can just use the macros directly in Makefile. On platforms where these are not required, they will evaluate to empty. Platforms tested: Solaris 9 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=147419&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 linx.tech at yahoo.co.in Tue Feb 6 15:05:04 2007 From: linx.tech at yahoo.co.in (linx-tech user) Date: Tue, 6 Feb 2007 15:05:04 +0000 (GMT) Subject: [Fedora-directory-devel] Customize Directory Console | Enable Samba User Attributes Message-ID: <141692.59109.qm@web7814.mail.in.yahoo.com> I have integrated Samba with FDS. Its working properly. There is an option to enable posix/NT attributes by choosing Enable 'Posix user' or NT user attributes. Similarly I need a samba attribute form for Samba User by which selecting it will show me all the Samba attributes rather than selecting them individually from advanced property. Any help would be greatly appreciated. Thanks! - M. Tnawas --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 6 15:06:07 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 06 Feb 2007 08:06:07 -0700 Subject: [Fedora-directory-devel] Customize Directory Console | Enable Samba User Attributes In-Reply-To: <141692.59109.qm@web7814.mail.in.yahoo.com> References: <141692.59109.qm@web7814.mail.in.yahoo.com> Message-ID: <45C8995F.1090606@redhat.com> linx-tech user wrote: > > I have integrated Samba with FDS. Its working properly. > There is an option to enable posix/NT attributes by choosing Enable > 'Posix user' or NT user attributes. > Similarly I need a samba attribute form for Samba User by which > selecting it will show me all the Samba attributes rather than > selecting them individually from advanced property. > > Any help would be greatly appreciated. Thanks! You would have to do some java hacking in order to add a Samba attributes panel. > > - M. Tnawas > > ------------------------------------------------------------------------ > Here?s a new way to find what you're looking for - Yahoo! Answers > > ------------------------------------------------------------------------ > > -- > 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 linx.tech at yahoo.co.in Tue Feb 6 15:27:35 2007 From: linx.tech at yahoo.co.in (linx-tech user) Date: Tue, 6 Feb 2007 15:27:35 +0000 (GMT) Subject: [Fedora-directory-devel] Customize Directory Console | Enable Samba User Attributes In-Reply-To: <45C8995F.1090606@redhat.com> Message-ID: <467511.84150.qm@web7803.mail.in.yahoo.com> I downloaded Fedora Directory (Console) source code and followed the steps from http://directory.fedora.redhat.com/wiki/BuildingConsole Also found the file which contains the code for accepting the user attributes for NT/Posix User but didnt get steps to rebuild it.. and dont know how to proceed. Richard Megginson wrote: linx-tech user wrote: > > I have integrated Samba with FDS. Its working properly. > There is an option to enable posix/NT attributes by choosing Enable > 'Posix user' or NT user attributes. > Similarly I need a samba attribute form for Samba User by which > selecting it will show me all the Samba attributes rather than > selecting them individually from advanced property. > > Any help would be greatly appreciated. Thanks! You would have to do some java hacking in order to add a Samba attributes panel. > > - M. Tnawas > > ------------------------------------------------------------------------ > Here?s a new way to find what you're looking for - Yahoo! Answers > > ------------------------------------------------------------------------ > > -- > 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 --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 6 15:36:30 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 06 Feb 2007 08:36:30 -0700 Subject: [Fedora-directory-devel] Customize Directory Console | Enable Samba User Attributes In-Reply-To: <467511.84150.qm@web7803.mail.in.yahoo.com> References: <467511.84150.qm@web7803.mail.in.yahoo.com> Message-ID: <45C8A07E.4060901@redhat.com> linx-tech user wrote: > I downloaded Fedora Directory (Console) source code and followed the > steps from http://directory.fedora.redhat.com/wiki/BuildingConsole > > Also found the file which contains the code for accepting the user > attributes for NT/Posix User but didnt get steps to rebuild it.. > and dont know how to proceed. Unfortunately it's not very well documented. However, there are some examples here - http://cvs.fedora.redhat.com/viewcvs/console/examples/?root=dirsec > > */Richard Megginson /* wrote: > > linx-tech user wrote: > > > > I have integrated Samba with FDS. Its working properly. > > There is an option to enable posix/NT attributes by choosing Enable > > 'Posix user' or NT user attributes. > > Similarly I need a samba attribute form for Samba User by which > > selecting it will show me all the Samba attributes rather than > > selecting them individually from advanced property. > > > > Any help would be greatly appreciated. Thanks! > You would have to do some java hacking in order to add a Samba > attributes panel. > > > > - M. Tnawas > > > > > ------------------------------------------------------------------------ > > Here?s a new way to find what you're looking for - Yahoo! Answers > > > > > ------------------------------------------------------------------------ > > > > -- > > 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 > > > ------------------------------------------------------------------------ > Here?s a new way to find what you're looking for - Yahoo! Answers > > ------------------------------------------------------------------------ > > -- > 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 rmeggins at redhat.com Wed Feb 7 17:04:51 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 07 Feb 2007 10:04:51 -0700 Subject: [Fedora-directory-devel] Please review: Bug 227618: FHS: move exes to _bindir; move ns-slapd to _sbindir Message-ID: <45CA06B3.2040102@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227618 Resolves: bug 227618 Bug Description: FHS: move exes to _bindir; move ns-slapd to _sbindir Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: In order to be more FHS compliant, we need to make the following changes: 1) move files executable by end users to _bindir (e.g. /usr/bin) - this means logconv.pl, ds_newinst, dbscan, etc. 2) move the server executable ns-slapd to _sbindir (e.g. /usr/sbin) And, to be more packaging friendly, the additional changes: 3) move libback-ldbm to the plugins dir - it is a plugin 4) use the libtool -avoid-version flag with plugins - we don't need the .so.0.0.0 for plugins I had to add support for sbindir and SBINDIR to create_instance and ds_newinst. We were using serverdir for 3 things - command line programs, server specific shared libs, and the server executable itself. These are now in 3 different places. The biggest change was to the scripts. I kept serverdir and SERVER-DIR to be the location of the server shared libs to avoid changing even more stuff. I had to add SERVERBIN-DIR to the scripts - this is the location of ns-slapd and is set by sbindir in create_instance (which defaults to SBINDIR from Makefile.am which defaults to $prefix/sbin in configure - whew). I've tested instance creation with these diffs - everything seems to work fine. Platforms tested: RHEL4, FC6 Flag Day: no Doc impact: Yes, but the docs will have to change quite a bit for all of the FHS related changes. https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147570&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 nkinder at redhat.com Wed Feb 7 22:28:22 2007 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 07 Feb 2007 14:28:22 -0800 Subject: [Fedora-directory-devel] Please Review: (227754) db.m4 needs to set the library path when using AC_CHECK_LIB Message-ID: <45CA5286.5010404@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227754 Resolves: bug 227754 Bug Description: Our db.m4 file checks for the db_create function in libdb-4.2.so. The problem is that it doesn't take the path that is passed in via "--with-db" when trying to locate the library. This causes configure to either use an incorrect system libdb , or configure fails on this check since it can't find libdb. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix simply adds the path to libdb as part of the library search path. I also updated some message formatting in a couple of our other m4 files to be consistent with the rest of our message formatting. Platforms tested: HP-UX 11iv2 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=147607 -------------- 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 Feb 8 18:20:38 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 08 Feb 2007 11:20:38 -0700 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location Message-ID: <45CB69F6.3040008@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227771 Resolves: bug 227771 Bug Description: FHS: use sysconfdir (/etc) as config file location Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: After much deliberation, we have decided that it is ok that our dynamic config files are under /etc/fedora-ds/slapd-instance. So the config_dir will be /etc/fedora-ds/slapd-instance and the security and schema files will go there as well. Since the FHS is ambiguous about this issue, and it will be very confusing if the configuration files are not under /etc, and there are some agents (webmin, cfengine) that do "dynamically" modify config files under /etc, this outweighs any considerations about having the server using it's config file like an "ascii database". In addition, the presence of repl-monitor-cgi causes rpm to complain, and since we only support CGIs in the Admin Server, this file has been removed from the core fedora-ds package. Platforms tested: RHEL4, FC6 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147685&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 prowley at redhat.com Fri Feb 9 04:23:00 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 08 Feb 2007 20:23:00 -0800 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <45CB69F6.3040008@redhat.com> References: <45CB69F6.3040008@redhat.com> Message-ID: <45CBF724.9090807@redhat.com> ok Richard Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227771 > Resolves: bug 227771 > Bug Description: FHS: use sysconfdir (/etc) as config file location > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: After much deliberation, we have decided that it is > ok that our dynamic config files are under /etc/fedora-ds/slapd-instance. > So the config_dir will be /etc/fedora-ds/slapd-instance and the > security and schema files will go there as well. Since the FHS is > ambiguous about this issue, and it will be very confusing if the > configuration files are not under /etc, and there are some agents > (webmin, cfengine) that do "dynamically" modify config files under > /etc, this outweighs any considerations about having the server using > it's config file like an "ascii database". > In addition, the presence of repl-monitor-cgi causes rpm to complain, > and since we only support CGIs in the Admin Server, this file has been > removed from the core fedora-ds package. > Platforms tested: RHEL4, FC6 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147685&action=diff > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- 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 abartlet at samba.org Fri Feb 9 09:57:46 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 09 Feb 2007 20:57:46 +1100 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <45CBF724.9090807@redhat.com> References: <45CB69F6.3040008@redhat.com> <45CBF724.9090807@redhat.com> Message-ID: <1171015066.19111.45.camel@localhost.localdomain> On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: > ok > > Richard Megginson wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227771 > > Resolves: bug 227771 > > Bug Description: FHS: use sysconfdir (/etc) as config file location > > Reviewed by: ??? > > Files: see diff > > Branch: HEAD > > Fix Description: After much deliberation, we have decided that it is > > ok that our dynamic config files are under /etc/fedora-ds/slapd-instance. > > So the config_dir will be /etc/fedora-ds/slapd-instance and the > > security and schema files will go there as well. Since the FHS is > > ambiguous about this issue, and it will be very confusing if the > > configuration files are not under /etc, and there are some agents > > (webmin, cfengine) that do "dynamically" modify config files under > > /etc, this outweighs any considerations about having the server using > > it's config file like an "ascii database". The debian folks (who take FHS seriously) won't buy that. The real test is the ability to have a read only /etc. This sounds like a /var/lib thing. Before you get into pain over this, I suggest finding a FHS expert. 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 Fri Feb 9 15:15:11 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Feb 2007 08:15:11 -0700 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <1171015066.19111.45.camel@localhost.localdomain> References: <45CB69F6.3040008@redhat.com> <45CBF724.9090807@redhat.com> <1171015066.19111.45.camel@localhost.localdomain> Message-ID: <45CC8FFF.1080207@redhat.com> Andrew Bartlett wrote: > On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: > >> ok >> >> Richard Megginson wrote: >> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227771 >>> Resolves: bug 227771 >>> Bug Description: FHS: use sysconfdir (/etc) as config file location >>> Reviewed by: ??? >>> Files: see diff >>> Branch: HEAD >>> Fix Description: After much deliberation, we have decided that it is >>> ok that our dynamic config files are under /etc/fedora-ds/slapd-instance. >>> So the config_dir will be /etc/fedora-ds/slapd-instance and the >>> security and schema files will go there as well. Since the FHS is >>> ambiguous about this issue, and it will be very confusing if the >>> configuration files are not under /etc, and there are some agents >>> (webmin, cfengine) that do "dynamically" modify config files under >>> /etc, this outweighs any considerations about having the server using >>> it's config file like an "ascii database". >>> > > The debian folks (who take FHS seriously) won't buy that. The real test > is the ability to have a read only /etc. This sounds like a /var/lib > thing. > > Before you get into pain over this, I suggest finding a FHS expert. > Does Debian forbid cfengine? webmin? If you do need to occasionally edit a config file, do you have to change the permissions on /etc to read-write, then change it back? Note that even files such as /etc/fstab can be dynamic as devices/filesystems are dynamically mounted/unmounted. Every FHS "expert" I've ever talked to (and I've talked to several) say the FHS is ambiguous with regards to this issue. > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From hyc at symas.com Fri Feb 9 17:18:11 2007 From: hyc at symas.com (Howard Chu) Date: Fri, 09 Feb 2007 09:18:11 -0800 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <20070209170021.2CD057324D@hormel.redhat.com> References: <20070209170021.2CD057324D@hormel.redhat.com> Message-ID: <45CCACD3.4020307@symas.com> > Date: Fri, 09 Feb 2007 08:15:11 -0700 > From: Richard Megginson > Andrew Bartlett wrote: >> > On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: >> > The debian folks (who take FHS seriously) won't buy that. The real test >> > is the ability to have a read only /etc. This sounds like a /var/lib >> > thing. >> > >> > Before you get into pain over this, I suggest finding a FHS expert. >> > > Does Debian forbid cfengine? webmin? If you do need to occasionally > edit a config file, do you have to change the permissions on /etc to > read-write, then change it back? For a lot of secure installs, yes, this is what's done. > Note that even files such as > /etc/fstab can be dynamic as devices/filesystems are dynamically > mounted/unmounted. Actually fstab is just a static file. You might be thinking of mtab. Some of these things just get symlinked to /var/run which is writable. -- -- 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 rmeggins at redhat.com Fri Feb 9 17:37:19 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Feb 2007 10:37:19 -0700 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <45CCACD3.4020307@symas.com> References: <20070209170021.2CD057324D@hormel.redhat.com> <45CCACD3.4020307@symas.com> Message-ID: <45CCB14F.80806@redhat.com> Howard Chu wrote: >> Date: Fri, 09 Feb 2007 08:15:11 -0700 > > From: Richard Megginson > >> Andrew Bartlett wrote: >>> > On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: > >>> > The debian folks (who take FHS seriously) won't buy that. The >>> real test >>> > is the ability to have a read only /etc. This sounds like a /var/lib >>> > thing. > >>> > Before you get into pain over this, I suggest finding a FHS expert. >>> > >> Does Debian forbid cfengine? webmin? If you do need to occasionally >> edit a config file, do you have to change the permissions on /etc to >> read-write, then change it back? > > For a lot of secure installs, yes, this is what's done. What does openldap do on those systems when using back-config? Do you have a symlink from /etc/openldap/config to /var/whatever, so that people looking for some config can find it? > > > Note that even files such as >> /etc/fstab can be dynamic as devices/filesystems are dynamically >> mounted/unmounted. > > Actually fstab is just a static file. You might be thinking of mtab. > Some of these things just get symlinked to /var/run which is writable. No, on my system /etc/fstab is dynamically updated - so is /etc/mtab. I guess what I'm trying to determine is - who can definitively answer this question? However, if /etc really is sometimes mounted read-only, then there are a couple of options: 1) Always put our config files under /var/lib/fedora-ds/slapd-instance, and just create a symlink /etc/fedora-ds/slapd-instance that points to /var/lib/fedora-ds/slapd-instance 2) Have the location be distro specific e.g. debian and derived packages will use /var/lib, fedora derived packages will use /etc At any rate, it should be a configure option. -------------- 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 dennis at ausil.us Fri Feb 9 18:40:27 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 9 Feb 2007 12:40:27 -0600 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <45CCB14F.80806@redhat.com> References: <20070209170021.2CD057324D@hormel.redhat.com> <45CCACD3.4020307@symas.com> <45CCB14F.80806@redhat.com> Message-ID: <200702091240.27365.dennis@ausil.us> On Friday 09 February 2007 11:37, Richard Megginson wrote: > Howard Chu wrote: > >> Date: Fri, 09 Feb 2007 08:15:11 -0700 > >> > > > From: Richard Megginson > >> > >> Andrew Bartlett wrote: > >>> > On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: > >>> > > >>> > The debian folks (who take FHS seriously) won't buy that. The > >>> > >>> real test > >>> > >>> > is the ability to have a read only /etc. This sounds like a /var/lib > >>> > thing. > > >>> > Before you get into pain over this, I suggest finding a FHS expert. > >> > >> Does Debian forbid cfengine? webmin? If you do need to occasionally > >> edit a config file, do you have to change the permissions on /etc to > >> read-write, then change it back? > > > > For a lot of secure installs, yes, this is what's done. > > What does openldap do on those systems when using back-config? Do you > have a symlink from /etc/openldap/config to /var/whatever, so that > people looking for some config can find it? > > > > Note that even files such as > >> > >> /etc/fstab can be dynamic as devices/filesystems are dynamically > >> mounted/unmounted. > > > > Actually fstab is just a static file. You might be thinking of mtab. > > Some of these things just get symlinked to /var/run which is writable. > > No, on my system /etc/fstab is dynamically updated - so is /etc/mtab. hal dynamically adjusts fstab now when you hot plug devices that can be mounted. > I guess what I'm trying to determine is - who can definitively answer > this question? > > However, if /etc really is sometimes mounted read-only, then there are a > couple of options: 1) your on crack 2) you are on some embeded something funky and most of your filesystem is read only you need to create funky symlinks. openwrt comes to mind. and you know how to deal with it . -- Dennis Gilmore, RHCE From rmeggins at redhat.com Fri Feb 9 21:36:54 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Feb 2007 14:36:54 -0700 Subject: [Fedora-directory-devel] Please review: Bug 160235: Add support for /etc/init scripts Message-ID: <45CCE976.5000204@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160235 Resolves: bug 160235 Bug Description: Add support for /etc/init scripts Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Add the new initscript. The initscript is called $PACKAGE_NAME which by default is fedora-ds. This script is created from wrappers/initscript.in, sed'd by the fixupcmd in Makefile.am during make install. The way it works is this: service fedora-ds cmd will execute the cmd on all instances (found in /etc/fedora-ds by default). service fedora-ds cmd instance will execute cmd on only that instance. So if you have /etc/fedora-ds/slapd-foo /etc/fedora-ds/slapd-bar and you do service start fedora-ds it will start up both slapd-foo and slapd-bar. If you do service start fedora-ds bar it will start up only slapd-bar. If you do service start fedora-ds biff you will get an error message. The initdir is platform specific (e.g. /etc/rc.d/init.d on linux, /etc/init.d on Solaris, ?? on hpux) so the definition was added to the platform dependent section of configure.ac. The init script is explicitly branded, including the filename. I needed to add support to the autotool files so that we could change the name of the file. Since package_name is defined when you use the AC_INIT macro in configure.ac, we don't need to define it elsewhere (e.g. #define BRAND_DS). So I added the branding and other information to the autotool files, and changed create_instance to use package_name instead of brand_ds to be consistent. Having the package_name defined in much fewer places should make it much easier to change in the future if necessary. I also fixed a compiler warning in ldaprot.h. Platforms tested: RHEL4, FC6 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none Diffs: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147814&action=diff New initscript.in: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147815 -------------- 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 Fri Feb 9 21:43:17 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 10 Feb 2007 08:43:17 +1100 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <200702091240.27365.dennis@ausil.us> References: <20070209170021.2CD057324D@hormel.redhat.com> <45CCACD3.4020307@symas.com> <45CCB14F.80806@redhat.com> <200702091240.27365.dennis@ausil.us> Message-ID: <1171057397.19111.50.camel@localhost.localdomain> On Fri, 2007-02-09 at 12:40 -0600, Dennis Gilmore wrote: > On Friday 09 February 2007 11:37, Richard Megginson wrote: > > Howard Chu wrote: > > >> Date: Fri, 09 Feb 2007 08:15:11 -0700 > > >> > > > > From: Richard Megginson > > >> > > >> Andrew Bartlett wrote: > > >>> > On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: > > >>> > > > >>> > The debian folks (who take FHS seriously) won't buy that. The > > >>> > > >>> real test > > >>> > > >>> > is the ability to have a read only /etc. This sounds like a /var/lib > > >>> > thing. > > > >>> > Before you get into pain over this, I suggest finding a FHS expert. > > >> > > >> Does Debian forbid cfengine? webmin? If you do need to occasionally > > >> edit a config file, do you have to change the permissions on /etc to > > >> read-write, then change it back? > > > > > > For a lot of secure installs, yes, this is what's done. > > > > What does openldap do on those systems when using back-config? Do you > > have a symlink from /etc/openldap/config to /var/whatever, so that > > people looking for some config can find it? > > > > > > Note that even files such as > > >> > > >> /etc/fstab can be dynamic as devices/filesystems are dynamically > > >> mounted/unmounted. > > > > > > Actually fstab is just a static file. You might be thinking of mtab. > > > Some of these things just get symlinked to /var/run which is writable. > > > > No, on my system /etc/fstab is dynamically updated - so is /etc/mtab. > hal dynamically adjusts fstab now when you hot plug devices that can be > mounted. This is changing. Later systems (like FC5) don't change the fstab any more. > > I guess what I'm trying to determine is - who can definitively answer > > this question? > > > > However, if /etc really is sometimes mounted read-only, then there are a > > couple of options: > 1) your on crack > 2) you are on some embeded something funky and most of your filesystem is read > only you need to create funky symlinks. openwrt comes to mind. and you > know how to deal with it . It's more than that. NFS root systems are typically like this too, when setup using the 'stateless Linux' toolchain. 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 nkinder at redhat.com Fri Feb 9 21:52:29 2007 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 09 Feb 2007 13:52:29 -0800 Subject: [Fedora-directory-devel] Please Review: (228082) Wrappers need to support legacy bundled builds Message-ID: <45CCED1D.9000903@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228082 Resolves: 228082 Bug Description: We still need to support legacy-style bundled builds where we bundle all of our run-time dependencies with the directory server itself. With the current build-system, we use the library paths that are used at link-time to set the library search path in our wrapper scripts. This will not work for the old style bundled builds. We should only be using libpath (/opt/fedora-ds/lib by default) in the wrappers. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix adds a new "--enable-bundle" configure option that will only be used for legacy-style packaging. Using this option will make the build use a different sed command for wrapper creation. Platforms tested: HP-UX 11iv2 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147818&action=edit -------------- 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 Sat Feb 10 00:23:48 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Feb 2007 17:23:48 -0700 Subject: [Fedora-directory-devel] Read only config (was: FHS: use sysconfdir (/etc) as config file location) In-Reply-To: <1171057397.19111.50.camel@localhost.localdomain> References: <20070209170021.2CD057324D@hormel.redhat.com> <45CCACD3.4020307@symas.com> <45CCB14F.80806@redhat.com> <200702091240.27365.dennis@ausil.us> <1171057397.19111.50.camel@localhost.localdomain> Message-ID: <45CD1094.10101@redhat.com> Andrew Bartlett wrote: > On Fri, 2007-02-09 at 12:40 -0600, Dennis Gilmore wrote: > >> On Friday 09 February 2007 11:37, Richard Megginson wrote: >> >>> Howard Chu wrote: >>> >>>>> Date: Fri, 09 Feb 2007 08:15:11 -0700 >>>>> >>>>> From: Richard Megginson >>>>> >>>>> Andrew Bartlett wrote: >>>>> >>>>>>> On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: >>>>>>> >>>>>>> The debian folks (who take FHS seriously)won't buy that. The >>>>>>> >>>>>> real test >>>>>> >>>>>> >>>>>>> is the ability to have a read only /etc. This sounds like a /var/lib >>>>>>> thing. > >>>>>>> I think there are two things which are required by Fedora DS to satisfy the requirements. 1) Need to be able to specify, during configure, the default path for instance specific writable config files. This would allow you to do something like: ./configure --with-instconfigdir=/var/lib/fedora-ds .... If not specified, the default would be $(sysconfigdir)/$(PACKAGE_NAME). When you specify this, you can use ds_newinst.pl to create a new instance without having to specify config_dir=/var/lib/fedora-ds/slapd-instance in your .inf file. I think this would solve the immediate problem. However, the real problem here is that you may want to run your server with a read-only config for security reasons. so 2) Need to be able to run the server with read-only config. The first time the server starts up, it would need to have a writable config dir, but after that, it should be able to run with a read-only config. This would involve several changes to the server, and would necessitate adding another server directory to store state information (or just use the dbdir for this). I think the uuid gen and csn gen (and now the dna plugin) need to store state information which is now stored in dse.ldif. We would have to move this information to some other location. -------------- 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 prowley at redhat.com Sat Feb 10 00:56:46 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 09 Feb 2007 16:56:46 -0800 Subject: [Fedora-directory-devel] Read only config In-Reply-To: <45CD1094.10101@redhat.com> References: <20070209170021.2CD057324D@hormel.redhat.com> <45CCACD3.4020307@symas.com> <45CCB14F.80806@redhat.com> <200702091240.27365.dennis@ausil.us> <1171057397.19111.50.camel@localhost.localdomain> <45CD1094.10101@redhat.com> Message-ID: <45CD184E.7080601@redhat.com> Richard Megginson wrote: > Andrew Bartlett wrote: >> On Fri, 2007-02-09 at 12:40 -0600, Dennis Gilmore wrote: >> >>> On Friday 09 February 2007 11:37, Richard Megginson wrote: >>> >>>> Howard Chu wrote: >>>> >>>>>> Date: Fri, 09 Feb 2007 08:15:11 -0700 >>>>>> >>>>>> From: Richard Megginson >>>>>> >>>>>> Andrew Bartlett wrote: >>>>>> >>>>>>>> On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: >>>>>>>> >>>>>>>> The debian folks (who take FHS seriously)won't buy that. The >>>>>>>> >>>>>>> real test >>>>>>> >>>>>>> >>>>>>>> is the ability to have a read only /etc. This sounds like a >>>>>>>> /var/lib >>>>>>>> thing. > >>>>>>>> > I think there are two things which are required by Fedora DS to > satisfy the requirements. > 1) Need to be able to specify, during configure, the default path for > instance specific writable config files. This would allow you to do > something like: > ./configure --with-instconfigdir=/var/lib/fedora-ds .... > If not specified, the default would be > $(sysconfigdir)/$(PACKAGE_NAME). When you specify this, you can use > ds_newinst.pl to create a new instance without having to specify > config_dir=/var/lib/fedora-ds/slapd-instance in your .inf file. I > think this would solve the immediate problem. > > However, the real problem here is that you may want to run your server > with a read-only config for security reasons. so > 2) Need to be able to run the server with read-only config. The first > time the server starts up, it would need to have a writable config > dir, but after that, it should be able to run with a read-only > config. This would involve several changes to the server, and would > necessitate adding another server directory to store state information > (or just use the dbdir for this). I think the uuid gen and csn gen > (and now the dna plugin) need to store state information which is now > stored in dse.ldif. We would have to move this information to some > other location. We might consider having a particular subtree for dynamic configuration i.e. that which is updated automatically with persistent run time state changes rather than as a consequence of direct admin initiated config changes, we could then make that a separate back-ldif backend with its own location. -- 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 prowley at redhat.com Sat Feb 10 01:01:31 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 09 Feb 2007 17:01:31 -0800 Subject: [Fedora-directory-devel] Read only config In-Reply-To: <45CD184E.7080601@redhat.com> References: <20070209170021.2CD057324D@hormel.redhat.com> <45CCACD3.4020307@symas.com> <45CCB14F.80806@redhat.com> <200702091240.27365.dennis@ausil.us> <1171057397.19111.50.camel@localhost.localdomain> <45CD1094.10101@redhat.com> <45CD184E.7080601@redhat.com> Message-ID: <45CD196B.4040308@redhat.com> Pete Rowley wrote: > Richard Megginson wrote: >> Andrew Bartlett wrote: >>> On Fri, 2007-02-09 at 12:40 -0600, Dennis Gilmore wrote: >>> >>>> On Friday 09 February 2007 11:37, Richard Megginson wrote: >>>> >>>>> Howard Chu wrote: >>>>> >>>>>>> Date: Fri, 09 Feb 2007 08:15:11 -0700 >>>>>>> >>>>>>> From: Richard Megginson >>>>>>> >>>>>>> Andrew Bartlett wrote: >>>>>>> >>>>>>>>> On Thu, 2007-02-08 at 20:23 -0800, Pete Rowley wrote: >>>>>>>>> >>>>>>>>> The debian folks (who take FHS seriously)won't buy that. The >>>>>>>>> >>>>>>>> real test >>>>>>>> >>>>>>>> >>>>>>>>> is the ability to have a read only /etc. This sounds like a >>>>>>>>> /var/lib >>>>>>>>> thing. > >>>>>>>>> >> I think there are two things which are required by Fedora DS to >> satisfy the requirements. >> 1) Need to be able to specify, during configure, the default path for >> instance specific writable config files. This would allow you to do >> something like: >> ./configure --with-instconfigdir=/var/lib/fedora-ds .... >> If not specified, the default would be >> $(sysconfigdir)/$(PACKAGE_NAME). When you specify this, you can use >> ds_newinst.pl to create a new instance without having to specify >> config_dir=/var/lib/fedora-ds/slapd-instance in your .inf file. I >> think this would solve the immediate problem. >> >> However, the real problem here is that you may want to run your >> server with a read-only config for security reasons. so >> 2) Need to be able to run the server with read-only config. The >> first time the server starts up, it would need to have a writable >> config dir, but after that, it should be able to run with a read-only >> config. This would involve several changes to the server, and would >> necessitate adding another server directory to store state >> information (or just use the dbdir for this). I think the uuid gen >> and csn gen (and now the dna plugin) need to store state information >> which is now stored in dse.ldif. We would have to move this >> information to some other location. > We might consider having a particular subtree for dynamic > configuration i.e. that which is updated automatically with persistent > run time state changes rather than as a consequence of direct admin > initiated config changes, we could then make that a separate > back-ldif backend with its own location. Or, for performance reasons - dbm. -- 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 hyc at symas.com Sat Feb 10 01:29:12 2007 From: hyc at symas.com (Howard Chu) Date: Fri, 09 Feb 2007 17:29:12 -0800 Subject: [Fedora-directory-devel] Re: Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <20070210010140.35D2B7314C@hormel.redhat.com> References: <20070210010140.35D2B7314C@hormel.redhat.com> Message-ID: <45CD1FE8.1070000@symas.com> > Date: Fri, 09 Feb 2007 10:37:19 -0700 > From: Richard Megginson >>> >> Date: Fri, 09 Feb 2007 08:15:11 -0700 >>> > > From: Richard Megginson >>> >> Does Debian forbid cfengine? webmin? If you do need to occasionally >>> >> edit a config file, do you have to change the permissions on /etc to >>> >> read-write, then change it back? >> > >> > For a lot of secure installs, yes, this is what's done. > What does openldap do on those systems when using back-config? Do you > have a symlink from /etc/openldap/config to /var/whatever, so that > people looking for some config can find it? OpenLDAP doesn't really offer any recommendations here. I guess the answer depends on what you're trying to isolate. A couple of Symas customers have deployed CDS using the back-ldap proxy in their DMZ as a frontend to their main directory servers (which, at the time, were not running on CDS). The motivation was that their servers were vulnerable to a number of malformed packet attacks (e.g., they crash unpredictably when faced with PROTOS). In these cases, once the configuration was created, it could be cast in stone. There's no local state info that changes at runtime. If you actually wanted to run a mostly read-only secure server, but you could accept the risk of having a writable config, then yes, symlinking from /etc/something to /var/wherever would probably be the approach I would use. -- -- 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 linx.tech at yahoo.co.in Sat Feb 10 19:53:26 2007 From: linx.tech at yahoo.co.in (linx-tech user) Date: Sat, 10 Feb 2007 19:53:26 +0000 (GMT) Subject: [Fedora-directory-devel] Unique mail-id Message-ID: <541425.10535.qm@web7804.mail.in.yahoo.com> By default, unique attribute is uid. How to have mailid also set as unique. I tried with the "unique" plugin but it doesn't work. Before adding an entry, I want to check for unique mailid and uid. Any help? Thanks - M. Tnawas --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Feb 12 18:16:46 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 12 Feb 2007 11:16:46 -0700 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location Message-ID: <45D0AF0E.6010806@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227771 Resolves: bug 227771 Bug Description: FHS: use sysconfdir (/etc) as config file location - allow builders to set dynamic config directory location at configure time Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I've added a new configure switch: --with-instconfigdir. This switch will allow the user to specify a different location to store the dynamic instance specific config files rather than the default $sysconfdir/$package_name (e.g. /etc/fedora-ds). This is the directory which will contain the slapd-instance directories which contain the instance specific config, schema, and security files. Even though the user could override this with ds_newinst.pl ([slapd] section config_dir), we needed to be able to set the default so that the user would not have to remember to do this every time, and so that packagers could set a reasonable default value for their platform. Platforms tested: FC6, RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147916&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 prowley at redhat.com Mon Feb 12 19:03:54 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 12 Feb 2007 11:03:54 -0800 Subject: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location In-Reply-To: <45D0AF0E.6010806@redhat.com> References: <45D0AF0E.6010806@redhat.com> Message-ID: <45D0BA1A.3080607@redhat.com> ok Richard Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227771 > Resolves: bug 227771 > Bug Description: FHS: use sysconfdir (/etc) as config file location - > allow builders to set dynamic config directory location at configure time > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: I've added a new configure switch: > --with-instconfigdir. This switch will allow the user to specify a > different location to store the dynamic instance specific config files > rather than the default $sysconfdir/$package_name (e.g. > /etc/fedora-ds). This is the directory which will contain the > slapd-instance directories which contain the instance specific config, > schema, and security files. Even though the user could override this > with ds_newinst.pl ([slapd] section config_dir), we needed to be able > to set the default so that the user would not have to remember to do > this every time, and so that packagers could set a reasonable default > value for their platform. > Platforms tested: FC6, RHEL4 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=147916&action=diff > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- 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 rmeggins at redhat.com Mon Feb 12 19:24:12 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 12 Feb 2007 12:24:12 -0700 Subject: [Fedora-directory-devel] Please review: Bug 228334: Allow building with bdb 4.4 or later Message-ID: <45D0BEDC.5020207@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228334 Resolves: bug 228334 Bug Description: Allow building with bdb 4.4 or later Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: db.m4 already had code to detect and use the correct version of db headers and libraries. There have been some minor api changes since 4.3, so not much code changes were required. Note that this merely allows the server to build and run with db4.4 or later, not to take advantage of the newer features of the API. Platforms tested: FC7 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=147925&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 Feb 16 22:12:16 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 16 Feb 2007 15:12:16 -0700 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" Message-ID: <45D62C40.70009@redhat.com> As we found out the hard way, the new Fedora Extras fedora-ds package conflicts with existing fedora-ds 1.0.x installations. I've tried Conflicts: fedora-ds < 1.1 and Conflicts: fedora-ds <= 1.0.4 neither one prevents you from installing fedora-ds 1.1 on top of your fedora-ds 1.0.4 installation and removing the admin server and console. I propose that we change the package naming to reflect the actual contents. So, the current fedora-ds 1.1 would be called fedora-ds-core, which is really what it is - the core LDAP server and command line tools - the core functionality. Subsequent packages would follow this convention: fedora-ds-admin, fedora-ds-console, etc. We could then have a fedora-ds "meta package" which had nothing in it but dependencies on fedora-ds-core, fedora-ds-admin, etc. and perhaps a few scripts, so that you could 'yum install fedora-ds' and it would install the same functionality as the fedora-ds 1.0.4 package. -------------- 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 dennis at ausil.us Fri Feb 16 22:19:08 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 16 Feb 2007 16:19:08 -0600 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" In-Reply-To: <45D62C40.70009@redhat.com> References: <45D62C40.70009@redhat.com> Message-ID: <200702161619.08635.dennis@ausil.us> On Friday 16 February 2007 04:12:16 pm Richard Megginson wrote: > As we found out the hard way, the new Fedora Extras fedora-ds package > conflicts with existing fedora-ds 1.0.x installations. I've tried > Conflicts: fedora-ds < 1.1 > and > Conflicts: fedora-ds <= 1.0.4 > neither one prevents you from installing fedora-ds 1.1 on top of your > fedora-ds 1.0.4 installation and removing the admin server and console. > > I propose that we change the package naming to reflect the actual > contents. So, the current fedora-ds 1.1 would be called fedora-ds-core, > which is really what it is - the core LDAP server and command line tools > - the core functionality. > > Subsequent packages would follow this convention: fedora-ds-admin, > fedora-ds-console, etc. We could then have a fedora-ds "meta package" > which had nothing in it but dependencies on fedora-ds-core, > fedora-ds-admin, etc. and perhaps a few scripts, so that you could 'yum > install fedora-ds' and it would install the same functionality as the > fedora-ds 1.0.4 package. This gets a +1 from me -- Dennis Gilmore, RHCE From nkinder at redhat.com Fri Feb 16 22:20:09 2007 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 16 Feb 2007 14:20:09 -0800 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" In-Reply-To: <200702161619.08635.dennis@ausil.us> References: <45D62C40.70009@redhat.com> <200702161619.08635.dennis@ausil.us> Message-ID: <45D62E19.5050205@redhat.com> Dennis Gilmore wrote: > On Friday 16 February 2007 04:12:16 pm Richard Megginson wrote: > >> As we found out the hard way, the new Fedora Extras fedora-ds package >> conflicts with existing fedora-ds 1.0.x installations. I've tried >> Conflicts: fedora-ds < 1.1 >> and >> Conflicts: fedora-ds <= 1.0.4 >> neither one prevents you from installing fedora-ds 1.1 on top of your >> fedora-ds 1.0.4 installation and removing the admin server and console. >> >> I propose that we change the package naming to reflect the actual >> contents. So, the current fedora-ds 1.1 would be called fedora-ds-core, >> which is really what it is - the core LDAP server and command line tools >> - the core functionality. >> >> Subsequent packages would follow this convention: fedora-ds-admin, >> fedora-ds-console, etc. We could then have a fedora-ds "meta package" >> which had nothing in it but dependencies on fedora-ds-core, >> fedora-ds-admin, etc. and perhaps a few scripts, so that you could 'yum >> install fedora-ds' and it would install the same functionality as the >> fedora-ds 1.0.4 package. >> > > This gets a +1 from me > > I think this is a good approach as well. -------------- 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 nkinder at redhat.com Fri Feb 16 23:19:24 2007 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 16 Feb 2007 15:19:24 -0800 Subject: [Fedora-directory-devel] Please Review: (229095) HP-UX build not using pthread properly Message-ID: <45D63BFC.8080504@redhat.com> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229095 Resolves: bug 229095 Bug Description: The autotools build-system is not using libpthread properly. I attempted to test a build, and while the compile worked, ds_newinst-bin immediately core dumped with an assertion from NSPR. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: According to the man page for pthread on HP-UX, we need to build with "-D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE" when using libpthread. We also need to ensure that libpthread is linked to our programs before libc. I added AC_DEFINE macros as well as adding "-lpthread" to AM_LDFLAGS for the HP-UX build. Platforms tested: HP-UX 11.23 ia64 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148253 -------------- 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 prowley at redhat.com Fri Feb 16 23:30:47 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 16 Feb 2007 15:30:47 -0800 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" In-Reply-To: <45D62E19.5050205@redhat.com> References: <45D62C40.70009@redhat.com> <200702161619.08635.dennis@ausil.us> <45D62E19.5050205@redhat.com> Message-ID: <45D63EA7.2050400@redhat.com> Nathan Kinder wrote: > Dennis Gilmore wrote: >> >> This gets a +1 from me >> > I think this is a good approach as well. Agreed. -- 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 rcritten at redhat.com Mon Feb 19 13:38:12 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Feb 2007 08:38:12 -0500 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" In-Reply-To: <45D62C40.70009@redhat.com> References: <45D62C40.70009@redhat.com> Message-ID: <45D9A844.5020102@redhat.com> Richard Megginson wrote: > As we found out the hard way, the new Fedora Extras fedora-ds package > conflicts with existing fedora-ds 1.0.x installations. I've tried > Conflicts: fedora-ds < 1.1 > and > Conflicts: fedora-ds <= 1.0.4 > neither one prevents you from installing fedora-ds 1.1 on top of your > fedora-ds 1.0.4 installation and removing the admin server and console. > > I propose that we change the package naming to reflect the actual > contents. So, the current fedora-ds 1.1 would be called fedora-ds-core, > which is really what it is - the core LDAP server and command line tools > - the core functionality. > > Subsequent packages would follow this convention: fedora-ds-admin, > fedora-ds-console, etc. We could then have a fedora-ds "meta package" > which had nothing in it but dependencies on fedora-ds-core, > fedora-ds-admin, etc. and perhaps a few scripts, so that you could 'yum > install fedora-ds' and it would install the same functionality as the > fedora-ds 1.0.4 package. > I think I'd suggest the name fedora-ds-base. The word 'core' could be confusing to some, esp on non-Fedora platforms. It also aligns itself with another large system broken into pieces, KDE (kdebase kdelibs, etc). 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 rmeggins at redhat.com Mon Feb 19 16:44:33 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 19 Feb 2007 09:44:33 -0700 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" In-Reply-To: <45D9A844.5020102@redhat.com> References: <45D62C40.70009@redhat.com> <45D9A844.5020102@redhat.com> Message-ID: <45D9D3F1.5020002@redhat.com> Rob Crittenden wrote: > Richard Megginson wrote: >> As we found out the hard way, the new Fedora Extras fedora-ds package >> conflicts with existing fedora-ds 1.0.x installations. I've tried >> Conflicts: fedora-ds < 1.1 >> and >> Conflicts: fedora-ds <= 1.0.4 >> neither one prevents you from installing fedora-ds 1.1 on top of your >> fedora-ds 1.0.4 installation and removing the admin server and console. >> >> I propose that we change the package naming to reflect the actual >> contents. So, the current fedora-ds 1.1 would be called >> fedora-ds-core, which is really what it is - the core LDAP server and >> command line tools - the core functionality. >> >> Subsequent packages would follow this convention: fedora-ds-admin, >> fedora-ds-console, etc. We could then have a fedora-ds "meta >> package" which had nothing in it but dependencies on fedora-ds-core, >> fedora-ds-admin, etc. and perhaps a few scripts, so that you could >> 'yum install fedora-ds' and it would install the same functionality >> as the fedora-ds 1.0.4 package. >> > > I think I'd suggest the name fedora-ds-base. The word 'core' could be > confusing to some, esp on non-Fedora platforms. It also aligns itself > with another large system broken into pieces, KDE (kdebase kdelibs, etc). Hmm - does "base" connotate "standalone"? That is, would someone who installed fedora-ds-base expect to be able to run a complete LDAP server service? Or would they expect that, in addition to "base", they would have to install some additional packages in order to be operational? The same questions apply for "core". Other synonyms are - "root", "kernel", "crux", and my personal favorite "quintessence" > > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Mon Feb 19 22:08:16 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 19 Feb 2007 14:08:16 -0800 Subject: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets) Message-ID: <45DA1FD0.70507@redhat.com> This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). Heimdal uses this feature exclusively for its directory interactions (making it incompatible with other LDAP directories), and Samba testing is often performed over unix domain sockets (a convenience for them). There are advantages: no TCP overhead for local connections, the ability to test for the OS level user credentials, and AFAIK, an unsniffable transport without additional requirements. On that last point, I welcome arguments to the contrary. The socket file is created as var/run/fedora-ds/slapd-.socket by default, but this can be modified in configuration. I'm actually not sure where the best place to put this is since access control along the path to the socket matters. The socket itself is chmodded to give rw to owner, groups, and other by the server upon creation. I've added LDAPI auto authentication / bind, which basically means that if you access the DS over LDAPI it will trust the OS level auth and automatically bind you at connection open (i.e. the server won't wait for an explicit bind). There are several options to this: 1. You can turn auto binding on or off 2. You can specify a dn that root should be bound as (e.g. directory manager, or perhaps an admin account) 3. You can specify that the user maps to an existing entry via admin specified attributes - which are probably going to be uidNumber and gidNumber (the default) - root can be bound this way too, and this method takes precedence over 2. 4. In the event that the other methods are turned off, or do not result in bind credentials, you can specify that a DN be constructed for the bind DN and supply a suffix for the DN - this allows non-mapped entries to look sensible, you may use this feature to specifiy a suffix that works with existing access control for example. When auto binding is on, and option 4. is set, or option 2. is set and the unix user credentials match a single entry in the DIT, users are automatically bound at connection open and anonymous binds are impossible since an anonymous bind attempt is modified to the credentials used at connection open. Non-anonymous binds work as usual. This means that scripts and so on can be "dumb" and credentials need not be left lying around for snoopers, users on the local machine not be concerned with credentials either, and yet all connections can be subject to targetted access control. All configuration is dynamically observed except for the socket file location and the LDAPI switch itself - these require a server restart for the same reasons TCP port modification does - the socket must be created with root privilege prior to suing to its execution user. Cross platform code for OS level authentication is currently defined out (other than linux), I intend to enable that as testing for these platforms progresses. Diff: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=diff Additional files: getsocketpeer.c: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371 getsocketpeer.h: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148372 -- 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 prowley at redhat.com Mon Feb 19 22:18:21 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 19 Feb 2007 14:18:21 -0800 Subject: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DA1FD0.70507@redhat.com> References: <45DA1FD0.70507@redhat.com> Message-ID: <45DA222D.9030409@redhat.com> You might like to use this link to skip passed the autotools skunk in the diff: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=diff#ldap/admin/src/create_instance.c_sec1 Pete Rowley wrote: > This is a feature that exists in OpenLDAP (but has no RFC that I am > aware of). > Heimdal uses this feature exclusively for its directory interactions > (making it > incompatible with other LDAP directories), and Samba testing is often > performed > over unix domain sockets (a convenience for them). There are > advantages: no TCP > overhead for local connections, the ability to test for the OS level user > credentials, and AFAIK, an unsniffable transport without additional > requirements. On that last point, I welcome arguments to the contrary. > > The socket file is created as > var/run/fedora-ds/slapd-.socket by > default, but this can be modified in configuration. I'm actually not > sure where > the best place to put this is since access control along the path to > the socket > matters. The socket itself is chmodded to give rw to owner, groups, > and other by > the server upon creation. > > I've added LDAPI auto authentication / bind, which basically means > that if you > access the DS over LDAPI it will trust the OS level auth and > automatically bind > you at connection open (i.e. the server won't wait for an explicit > bind). There > are several options to this: > > 1. You can turn auto binding on or off > 2. You can specify a dn that root should be bound as (e.g. directory > manager, or > perhaps an admin account) > 3. You can specify that the user maps to an existing entry via admin > specified > attributes - which are probably going to be uidNumber and gidNumber (the > default) - root can be bound this way too, and this method takes > precedence over 2. > 4. In the event that the other methods are turned off, or do not > result in bind > credentials, you can specify that a DN be constructed for the bind DN > and supply > a suffix for the DN - this allows non-mapped entries to look sensible, > you may > use this feature to specifiy a suffix that works with existing access > control > for example. > > When auto binding is on, and option 4. is set, or option 2. is set and > the unix > user credentials match a single entry in the DIT, users are > automatically bound > at connection open and anonymous binds are impossible since an > anonymous bind > attempt is modified to the credentials used at connection open. > Non-anonymous > binds work as usual. This means that scripts and so on can be "dumb" and > credentials need not be left lying around for snoopers, users on the > local > machine not be concerned with credentials either, and yet all > connections can be > subject to targetted access control. > > All configuration is dynamically observed except for the socket file > location > and the LDAPI switch itself - these require a server restart for the same > reasons TCP port modification does - the socket must be created with root > privilege prior to suing to its execution user. > > Cross platform code for OS level authentication is currently defined > out (other > than linux), I intend to enable that as testing for these platforms > progresses. > > Diff: > > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=diff > > Additional files: > > getsocketpeer.c: > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371 > getsocketpeer.h: > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148372 > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- 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 rmeggins at redhat.com Mon Feb 19 23:09:12 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 19 Feb 2007 16:09:12 -0700 Subject: [Fedora-directory-devel] Please review: Bug 229286: Solaris build: link shared libs correctly with libtool Message-ID: <45DA2E18.6000902@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229286 Resolves: bug 229286 Bug Description: Solaris build: link shared libs correctly with libtool Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: We have to use the $(CXXLINK) Makefile macro to build shared libs that use C++ code or link with C++ libs. In addition, Sun C++ link needs -lCstd and -lCrun. I added AC_DISABLE_STATIC so that we wouldn't generate all the .a libs we don't use. Lastly, but not leastly, libtool on rhel/fedora has a "feature" that adds several gcc-isms to the libtool script generated by configure. At best, these cause builds with non-gcc compilers to complain quite a bit, and at worst, cause the build to fail. I've added a sed command in configure to remove these gcc-isms from libtool on non-gcc platforms. Platforms tested: RHEL4, FC6, Solaris 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148375&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 Feb 20 03:11:07 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 19 Feb 2007 20:11:07 -0700 Subject: [Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core" In-Reply-To: <45D9A844.5020102@redhat.com> References: <45D62C40.70009@redhat.com> <45D9A844.5020102@redhat.com> Message-ID: <45DA66CB.6070506@redhat.com> Rob Crittenden wrote: > Richard Megginson wrote: >> As we found out the hard way, the new Fedora Extras fedora-ds package >> conflicts with existing fedora-ds 1.0.x installations. I've tried >> Conflicts: fedora-ds < 1.1 >> and >> Conflicts: fedora-ds <= 1.0.4 >> neither one prevents you from installing fedora-ds 1.1 on top of your >> fedora-ds 1.0.4 installation and removing the admin server and console. >> >> I propose that we change the package naming to reflect the actual >> contents. So, the current fedora-ds 1.1 would be called >> fedora-ds-core, which is really what it is - the core LDAP server and >> command line tools - the core functionality. >> >> Subsequent packages would follow this convention: fedora-ds-admin, >> fedora-ds-console, etc. We could then have a fedora-ds "meta >> package" which had nothing in it but dependencies on fedora-ds-core, >> fedora-ds-admin, etc. and perhaps a few scripts, so that you could >> 'yum install fedora-ds' and it would install the same functionality >> as the fedora-ds 1.0.4 package. >> > > I think I'd suggest the name fedora-ds-base. The word 'core' could be > confusing to some, esp on non-Fedora platforms. It also aligns itself > with another large system broken into pieces, KDE (kdebase kdelibs, etc). I did some package searching. -base appears to be much more commonly used than -core for this purpose, and -base seems to connote the basic functionality required in addition to being the base upon which other packages are built. So, I propose fedora-ds-base. Any objections? http://www.us.debian.org/distrib/packages#search_packages > > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Tue Feb 20 19:21:07 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 20 Feb 2007 14:21:07 -0500 Subject: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DA1FD0.70507@redhat.com> References: <45DA1FD0.70507@redhat.com> Message-ID: <1171999268.1641.31.camel@finch.boston.redhat.com> On Mon, 2007-02-19 at 14:08 -0800, Pete Rowley wrote: > The socket file is created as var/run/fedora-ds/slapd-.socket by > default, but this can be modified in configuration. I'm actually not sure where > the best place to put this is since access control along the path to the socket > matters. The socket itself is chmodded to give rw to owner, groups, and other by > the server upon creation. /var/run is the correct ancestor in the directory hierarchy. According to section 5 of FHS "System programs that maintain transient UNIX-domain sockets must place them in this directory [/var/run]". The fact it is also segregated into a subdirectory hierarchy by component name is also encouraged by FHS. > 3. You can specify that the user maps to an existing entry via admin specified > attributes - which are probably going to be uidNumber and gidNumber (the > default) - root can be bound this way too, and this method takes precedence over 2. uid is appropriate, I am less certain gid is an appropriate attribute to be considered during a bind. Correct me if I'm wrong, but group membership is not considered in any of the other bind mechanisms. Isn't bind essentially "authentication" for which the uid in this constrained case of OS certified credentials would be sufficient to assert authentication? OS group membership is a form of OS "authorization" which is not part of the LDAP bind authentication. The directory maintains it's own notion of group membership once the bind operation succeeds in authenticating the user thus establishing the user's group membership. -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From prowley at redhat.com Tue Feb 20 20:49:40 2007 From: prowley at redhat.com (Pete Rowley) Date: Tue, 20 Feb 2007 12:49:40 -0800 Subject: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <1171999268.1641.31.camel@finch.boston.redhat.com> References: <45DA1FD0.70507@redhat.com> <1171999268.1641.31.camel@finch.boston.redhat.com> Message-ID: <45DB5EE4.80502@redhat.com> John Dennis wrote: > On Mon, 2007-02-19 at 14:08 -0800, Pete Rowley wrote: > >> The socket file is created as var/run/fedora-ds/slapd-.socket by >> default, but this can be modified in configuration. I'm actually not sure where >> the best place to put this is since access control along the path to the socket >> matters. The socket itself is chmodded to give rw to owner, groups, and other by >> the server upon creation. >> > > /var/run is the correct ancestor in the directory hierarchy. According > to section 5 of FHS "System programs that maintain transient UNIX-domain > sockets must place them in this directory [/var/run]". The fact it is > also segregated into a subdirectory hierarchy by component name is also > encouraged by FHS. > > OK, that's good. >> 3. You can specify that the user maps to an existing entry via admin specified >> attributes - which are probably going to be uidNumber and gidNumber (the >> default) - root can be bound this way too, and this method takes precedence over 2. >> > > uid is appropriate, I am less certain gid is an appropriate attribute to > be considered during a bind. Correct me if I'm wrong, but group > membership is not considered in any of the other bind mechanisms. Certainly access control can be set up to deny/allow the ability to bind based on group membership. > Isn't > bind essentially "authentication" for which the uid in this constrained > case of OS certified credentials would be sufficient to assert > authentication? In most cases I think the answer is yes. > OS group membership is a form of OS "authorization" > which is not part of the LDAP bind authentication. The directory > maintains it's own notion of group membership once the bind operation > succeeds in authenticating the user thus establishing the user's group > membership. > Yes I understand and I agree. Note that the administrator may configure a single attribute (uid), so where a one to one mapping is required this will suffice. Here's the rationale for gid: This is partially a conflation of OS authentication and LDAP authentication, with autobind the server is trusting the OS level authentication, but adding a requirement for its own authentication purposes for this bind method - the gid - remember, this is just a mapping, a way to find the right unique entry in LDAP. This could be useful when you _do_ have multiple users mapped to the same uidNumber, but differ by gidNumber. Think of the root example: computer admin, department admin, domain admin - all map to uidNumber: 0 for the purposes of OS authentication, but for LDAP authentication these are very different identities that may be subject to differing access control e.g. computer admin gets to administer local computers, department admin gets to administer their department computers etc. Of course, there are other ways to achieve that, but when a deployment works that way already, supporting the capability is no bad thing. Hopefully, that makes sense. -- 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 nkinder at redhat.com Tue Feb 20 23:22:22 2007 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 20 Feb 2007 15:22:22 -0800 Subject: [Fedora-directory-devel] Please Review: (229428) ns-slapd not linking to C++ runtime on HP-UX Message-ID: <45DB82AE.3080808@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229428 Resolves: bug 229428 Bug Description: While testing the binaries from the autotools based build on HP-UX, I was unable to get ns-slapd to run due to an unresolved symbol. I was seeing the following errors in the errors log: error:[20/Feb/2007:10:31:55 -0800] - Netscape Portable Runtime error -5977: Unsatisfied data symbol '_ZTVN10__cxxabiv120__si_class_type_infoE' in load module '//opt/fedora-ds/lib/libicui18n.so.34'. On HP-UX, the program that contains the main() function must be linked with the C++ compiler (aCC -AA in our case) if it loads any C++ shared libraries. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Tell libtool to use CXXLINK for linking ns-slapd on HP-UX. Platforms tested: HP-UX 11.23 ia64 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=148457 -------------- 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 hyc at symas.com Wed Feb 21 01:21:45 2007 From: hyc at symas.com (Howard Chu) Date: Tue, 20 Feb 2007 17:21:45 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <20070220170028.D12CD736A4@hormel.redhat.com> References: <20070220170028.D12CD736A4@hormel.redhat.com> Message-ID: <45DB9EA9.9090605@symas.com> > Date: Mon, 19 Feb 2007 14:08:16 -0800 > From: Pete Rowley > This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). > Heimdal uses this feature exclusively for its directory interactions (making it > incompatible with other LDAP directories), and Samba testing is often performed > over unix domain sockets (a convenience for them). There are advantages: no TCP > overhead for local connections This turns out to be pretty significant too - using TCP connections to localhost, a connection soak test will use up all available port numbers in a matter of seconds, after which all connection attempts fail. (Because there is a mandatory 2MSL timeout before a closed port may be made available for reuse.) Using ldapi we can process thousands of connections per second indefinitely. (Perhaps someone ought to suggest to the kernel folks that a 2MSL timeout on loopback sockets is unnecessary, since presumably the TCP close handshake can't get misrouted/lost there. ;) -- -- 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 hyc at symas.com Wed Feb 21 01:07:07 2007 From: hyc at symas.com (Howard Chu) Date: Tue, 20 Feb 2007 17:07:07 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <20070220170028.D12CD736A4@hormel.redhat.com> References: <20070220170028.D12CD736A4@hormel.redhat.com> Message-ID: <45DB9B3B.8060403@symas.com> > Date: Mon, 19 Feb 2007 14:08:16 -0800 > From: Pete Rowley > This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). I don't remember when/where this feature originated. Checking CVS I see that Luke Howard did the initial commit, 2000-01-02. I'd guess it was part of his early work on XAD. Originally we didn't use getpeereid, and just relied on socket permissions for access control. We added getpeereid in 2002, first on Linux and then Solaris and other platforms followed. > Heimdal uses this feature exclusively for its directory interactions (making it > incompatible with other LDAP directories), Luke also wrote that part of Heimdal, no surprise there... > and Samba testing is often performed > over unix domain sockets (a convenience for them). ... > There are advantages: no TCP > overhead for local connections, the ability to test for the OS level user > credentials, and AFAIK, an unsniffable transport without additional > requirements. On that last point, I welcome arguments to the contrary. It's possible, if you have privileges to insert kernel modules. But I think that's for someone else to worry about, not in scope here. (I.e., if you have someone malicious who can do that, you've already lost the machine.) > The socket file is created as var/run/fedora-ds/slapd-.socket by > default, but this can be modified in configuration. I'm actually not sure where > the best place to put this is since access control along the path to the socket > matters. The socket itself is chmodded to give rw to owner, groups, and other by > the server upon creation. > I've added LDAPI auto authentication / bind, which basically means that if you > access the DS over LDAPI it will trust the OS level auth and automatically bind > you at connection open (i.e. the server won't wait for an explicit bind). There > are several options to this: I'd be a little concerned about this "auto bind". In OpenLDAP the credentials are only used if a SASL/EXTERNAL Bind is performed. In general I think it's poor policy to do something "magic" without a user actually requesting it. Especially where security is involved. Granted, a user could explicitly perform a Bind if they need to override the auto bind, but that's not the point. In typical LDAP use a session is anonymous until an explicit Bind has succeeded. IMO this behavior should be true regardless of the type of URL being used. E.g., with OpenLDAP right now, we can interchange ldap://, ldaps://, and ldapi:// URLs at will and apps see consistent behavior. > When auto binding is on, and option 4. is set, or option 2. is set and the unix > user credentials match a single entry in the DIT, users are automatically bound > at connection open and anonymous binds are impossible since an anonymous bind > attempt is modified to the credentials used at connection open. As above, changing the semantics of anonymous Bind is a bad idea. > All configuration is dynamically observed except for the socket file location > and the LDAPI switch itself - these require a server restart for the same > reasons TCP port modification does - the socket must be created with root > privilege prior to suing to its execution user. > Cross platform code for OS level authentication is currently defined out (other > than linux), I intend to enable that as testing for these platforms progresses. > > Diff: > > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=diff > > Additional files: > > getsocketpeer.c: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371 As noted in OpenLDAP's implementation, using MSG_PEEK will fail on AIX. But I guess you can worry about that when you actually have the code base ported to AIX... You might consider using the same API/name as OpenLDAP does, for source code compatibility, even though this isn't a function apps need to call themselves. (I.e., I can't think of a need for it at the moment, but one may spring up down the road.) -- -- 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 abartlet at samba.org Wed Feb 21 13:26:18 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 22 Feb 2007 00:26:18 +1100 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DB9B3B.8060403@symas.com> References: <20070220170028.D12CD736A4@hormel.redhat.com> <45DB9B3B.8060403@symas.com> Message-ID: <1172064378.10487.107.camel@localhost.localdomain> On Tue, 2007-02-20 at 17:07 -0800, Howard Chu wrote: > > The socket file is created as var/run/fedora-ds/slapd-.socket by > > default, but this can be modified in configuration. I'm actually not sure where > > the best place to put this is since access control along the path to the socket > > matters. The socket itself is chmodded to give rw to owner, groups, and other by > > the server upon creation. > > > I've added LDAPI auto authentication / bind, which basically means that if you > > access the DS over LDAPI it will trust the OS level auth and automatically bind > > you at connection open (i.e. the server won't wait for an explicit bind). There > > are several options to this: > > I'd be a little concerned about this "auto bind". In OpenLDAP the credentials > are only used if a SASL/EXTERNAL Bind is performed. In general I think it's > poor policy to do something "magic" without a user actually requesting it. > Especially where security is involved. Granted, a user could explicitly > perform a Bind if they need to override the auto bind, but that's not the > point. In typical LDAP use a session is anonymous until an explicit Bind has > succeeded. IMO this behavior should be true regardless of the type of URL > being used. E.g., with OpenLDAP right now, we can interchange ldap://, > ldaps://, and ldapi:// URLs at will and apps see consistent behavior. I agree. Autobinding is a bad idea, as even for Samba I want that consistency: we run as root, but unless I start passing credentials, I'm expecting the DB to be giving me anonymous access. 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 Wed Feb 21 16:34:03 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 21 Feb 2007 09:34:03 -0700 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <1172064378.10487.107.camel@localhost.localdomain> References: <20070220170028.D12CD736A4@hormel.redhat.com> <45DB9B3B.8060403@symas.com> <1172064378.10487.107.camel@localhost.localdomain> Message-ID: <45DC747B.3030506@redhat.com> Andrew Bartlett wrote: > On Tue, 2007-02-20 at 17:07 -0800, Howard Chu wrote: > > >>> The socket file is created as var/run/fedora-ds/slapd-.socket by >>> default, but this can be modified in configuration. I'm actually not sure where >>> the best place to put this is since access control along the path to the socket >>> matters. The socket itself is chmodded to give rw to owner, groups, and other by >>> the server upon creation. >>> >>> I've added LDAPI auto authentication / bind, which basically means that if you >>> access the DS over LDAPI it will trust the OS level auth and automatically bind >>> you at connection open (i.e. the server won't wait for an explicit bind). There >>> are several options to this: >>> >> I'd be a little concerned about this "auto bind". In OpenLDAP the credentials >> are only used if a SASL/EXTERNAL Bind is performed. In general I think it's >> poor policy to do something "magic" without a user actually requesting it. >> Especially where security is involved. Granted, a user could explicitly >> perform a Bind if they need to override the auto bind, but that's not the >> point. In typical LDAP use a session is anonymous until an explicit Bind has >> succeeded. IMO this behavior should be true regardless of the type of URL >> being used. E.g., with OpenLDAP right now, we can interchange ldap://, >> ldaps://, and ldapi:// URLs at will and apps see consistent behavior. >> > > I agree. Autobinding is a bad idea, as even for Samba I want that > consistency: we run as root, but unless I start passing credentials, > I'm expecting the DB to be giving me anonymous access. > Is it possible that in some cases you would want the DS to use the OS credentials? In a sense, when I login to the OS with my username/password or other credentials, I am "bound" to my session, my identity has been validated. So should this be another SASL mechanism? It's sort of like SASL/GSSAPI or SASL/EXTERNAL, in that the credentials are verified externally. Also, for Heimdal, I thought one of the benefits of using ldapi was that you could have more privileged access to the LDAP data without having to store authentication credentials and use them as would be used when accessing over TCP. > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From hyc at symas.com Wed Feb 21 17:35:55 2007 From: hyc at symas.com (Howard Chu) Date: Wed, 21 Feb 2007 09:35:55 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <20070221170028.48EA6732F2@hormel.redhat.com> References: <20070221170028.48EA6732F2@hormel.redhat.com> Message-ID: <45DC82FB.6050909@symas.com> > Date: Wed, 21 Feb 2007 09:34:03 -0700 > From: Richard Megginson >> Andrew Bartlett wrote: >> > On Tue, 2007-02-20 at 17:07 -0800, Howard Chu wrote: >>> >> I'd be a little concerned about this "auto bind". In OpenLDAP the credentials >>> >> are only used if a SASL/EXTERNAL Bind is performed. In general I think it's >>> >> poor policy to do something "magic" without a user actually requesting it. >>> >> Especially where security is involved. Granted, a user could explicitly >>> >> perform a Bind if they need to override the auto bind, but that's not the >>> >> point. In typical LDAP use a session is anonymous until an explicit Bind has >>> >> succeeded. IMO this behavior should be true regardless of the type of URL >>> >> being used. E.g., with OpenLDAP right now, we can interchange ldap://, >>> >> ldaps://, and ldapi:// URLs at will and apps see consistent behavior. >> > I agree. Autobinding is a bad idea, as even for Samba I want that >> > consistency: we run as root, but unless I start passing credentials, >> > I'm expecting the DB to be giving me anonymous access. > Is it possible that in some cases you would want the DS to use the OS > credentials? In a sense, when I login to the OS with my > username/password or other credentials, I am "bound" to my session, my > identity has been validated. Yes, this is precisely the use case for SASL/EXTERNAL, which is why we implemented it that way. > Also, for Heimdal, I thought one of the benefits of using ldapi was that > you could have more privileged access to the LDAP data without having to > store authentication credentials and use them as would be used when > accessing over TCP. Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to request this privilege. There is no assumption of automagic authorization. Even though the credentials are available, the server will not inspect them unless it receives a SASL/EXTERNAL Bind request. If it receives such a request, then it will construct a SASL authentication DN of the form gidNumber=GID+uidNumber=UID,cn=peercred,cn=external,cn=auth which then drops into the usual SASL identity mapper for optional munging into some other DN and that DN becomes the identity bound to the session. Note that RFC4513 section 4 states explicitly : Upon initial establishment of the LDAP session, the session has an anonymous authorization identity. Section 2 also states LDAP server implementations MUST support the anonymous authentication mechanism of the simple Bind method (Section 5.1.1). I think it's clear that an anonymous bind MUST actually give you an anonymous session state, not some other implicitly selected identity. -- -- 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 prowley at redhat.com Wed Feb 21 20:16:04 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 21 Feb 2007 12:16:04 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DC82FB.6050909@symas.com> References: <20070221170028.48EA6732F2@hormel.redhat.com> <45DC82FB.6050909@symas.com> Message-ID: <45DCA884.2030702@redhat.com> Howard Chu wrote: > >> Also, for Heimdal, I thought one of the benefits of using ldapi was >> that you could have more privileged access to the LDAP data without >> having to store authentication credentials and use them as would be >> used when accessing over TCP. > > Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to > request this privilege. There is no assumption of automagic > authorization. > Even though the credentials are available, the server will not inspect > them unless it receives a SASL/EXTERNAL Bind request. If it receives > such a request, then it will construct a SASL authentication DN of the > form > gidNumber=GID+uidNumber=UID,cn=peercred,cn=external,cn=auth > which then drops into the usual SASL identity mapper for optional > munging into some other DN and that DN becomes the identity bound to > the session. I guess we can add that. Rich and I have already talked about that as a TBD. > > Note that RFC4513 section 4 states explicitly : > Upon initial establishment of the LDAP session, the session has an > anonymous authorization identity. > Right. Note that this is an option, it can be turned off. > Section 2 also states > LDAP server implementations MUST support the anonymous authentication > mechanism of the simple Bind method (Section 5.1.1). > > I think it's clear that an anonymous bind MUST actually give you an > anonymous session state, not some other implicitly selected identity. The server does support the anonymous authentication mechanism ;) While observing RFC4513 is a good thing, and this implementation does so when auto-bind is switched off, I believe these kinds of decisions are the domain of site administrative policy and not of standards documents. Further, a client in the anonymous bind state has no practical knowledge of the effects of that state on server responses in any case, nor can it be sure that binding as a non-anonymous user has any effect on those responses, nor indeed does auto-bind necessarily remove or add any privilege for the client - that is all administrative policy and undefined by any RFC. This is just one more administrative policy option. In addition, LDAP is defined as it is in no small part to the underlying assumption of TCP and designed around the practical methods of authentication given that assumption, strictly speaking LDAPI isn't LDAP (it's not even platform agnostic), and LDAPI has other methods at its disposal. While I understand your concern, the feature is an option, not a requirement. -- 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 Wed Feb 21 21:50:18 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 21 Feb 2007 13:50:18 -0800 Subject: [Fedora-directory-devel] Commit: [Bug 229576] New: clean up template-scriptname which is derived from template-scriptname.in In-Reply-To: References: Message-ID: <45DCBE9A.3070107@redhat.com> Summary: clean up template-scriptname which is derived from template-scriptname.in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229576 Summary: clean up template-scriptname which is derived from template-scriptname.in Product: Fedora Directory Server Version: 1.0.4 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: normal Component: Admin AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ohegarty at redhat.com Estimated Hours: 0.0 The following files were removed from CVS. Please let me know if you find any problems caused by this change... ./ldap/admin/src/scripts/template-ldif2db.pl ./ldap/admin/src/scripts/template-db2bak ./ldap/admin/src/scripts/template-ns-activate.pl ./ldap/admin/src/scripts/template-vlvindex ./ldap/admin/src/scripts/template-verify-db.pl ./ldap/admin/src/scripts/template-ns-newpwpolicy.pl ./ldap/admin/src/scripts/template-ldif2db ./ldap/admin/src/scripts/template-ns-inactivate.pl ./ldap/admin/src/scripts/template-saveconfig ./ldap/admin/src/scripts/template-cl-dump.pl ./ldap/admin/src/scripts/template-restoreconfig ./ldap/admin/src/scripts/template-db2ldif ./ldap/admin/src/scripts/template-db2index ./ldap/admin/src/scripts/template-start-slapd ./ldap/admin/src/scripts/template-bak2db.pl ./ldap/admin/src/scripts/template-repl-monitor-cgi.pl ./ldap/admin/src/scripts/template-db2index.pl ./ldap/admin/src/scripts/template-bak2db ./ldap/admin/src/scripts/template-repl-monitor.pl ./ldap/admin/src/scripts/template-db2ldif.pl ./ldap/admin/src/scripts/template-ldif2ldap ./ldap/admin/src/scripts/template-db2bak.pl ./ldap/admin/src/scripts/template-suffix2instance ./ldap/admin/src/scripts/template-stop-slapd ./ldap/admin/src/scripts/template-ns-accountstatus.pl ./ldap/admin/src/scripts/template-monitor ./ldap/admin/src/ds_newinst.pl ------- Additional Comments From nhosoi at redhat.com 2007-02-21 16:19 EST ------- Created an attachment (id=148536) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148536&action=view) email discussion ------- Additional Comments From nhosoi at redhat.com 2007-02-21 16:24 EST ------- Created an attachment (id=148538) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148538&action=view) cvs commit message Removed from CVS HEAD. -------------- 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 Feb 22 21:05:02 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 22 Feb 2007 14:05:02 -0700 Subject: [Fedora-directory-devel] Please review: Bug 229691: Add enable switches for optional/experimental features Message-ID: <45DE057E.4050506@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229691 Resolves: bug 229691 Bug Description: Add enable switches for optional/experimental features Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Added --enable-pam-passthru, --enable-dna, and --enable-ldapi. They are all on by default and must be explicitly disabled (--disable-pam-passthru). These all cause ENABLE_xxx to be defined for C code so that we can enclose the code in #ifdef ENABLE_PAM_PASSTHRU blocks, for example. For the first two, these also cause the plugins to be built - so that if you specify --disable-pam-passthru, the plugin code will not be built at all. I discovered a nifty autoconf macro called AS_HELP_STRING - this nicely formats the help messages output by configure --help. I don't know if it's worth going through all of our m4 code to use this, but I went ahead and fixed configure.ac. Create instance will now add plugin configuration entries (but disabled) for pam passthru and dna if the corresponding ENABLE_ macros are defined. I also fixed a bug with passthru (not pam passthru) - the plugin configuration entry was not being added. Platforms tested: RHEL4, FC6 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148631&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 hyc at symas.com Thu Feb 22 21:55:17 2007 From: hyc at symas.com (Howard Chu) Date: Thu, 22 Feb 2007 13:55:17 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <20070222170030.D2D3673742@hormel.redhat.com> References: <20070222170030.D2D3673742@hormel.redhat.com> Message-ID: <45DE1145.1050403@symas.com> > Date: Wed, 21 Feb 2007 12:16:04 -0800 > From: Pete Rowley Sorry, I don't mean to beat too much on a dead horse, but ... > Howard Chu wrote: >> > Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to >> > request this privilege. There is no assumption of automagic >> > authorization. > I guess we can add that. Rich and I have already talked about that as a TBD. > While observing RFC4513 is a good thing, and this implementation does so > when auto-bind is switched off, I believe these kinds of decisions are > the domain of site administrative policy and not of standards documents. > Further, a client in the anonymous bind state has no practical knowledge > of the effects of that state on server responses in any case, nor can it > be sure that binding as a non-anonymous user has any effect on those > responses, nor indeed does auto-bind necessarily remove or add any > privilege for the client - that is all administrative policy and > undefined by any RFC. This is just one more administrative policy option. Certainly it's true that LDAP has nothing specific to say about authorization. But don't confuse authorization with authentication; they're two separate things. A client can easily determine that it's in an anonymous state, using the WhoAmI extended op. If "ldapwhoami -x -H ldapi:///" doesn't return a zero-length ID, then your server is broken. > In addition, LDAP is defined as it is in no small part to the underlying > assumption of TCP and designed around the practical methods of > authentication given that assumption, strictly speaking LDAPI isn't LDAP > (it's not even platform agnostic), and LDAPI has other methods at its > disposal. And again, don't confuse the protocol with the transport. Fuzzy thinking like that is one of the reasons we have LDAP today, instead of just DAP over TCP. Sure the RFCs only define LDAP in terms of TCP, but obviously any reliable, ordered, stream transport will work just as well. And in a proper library implementation, such a transport can be substituted between any client and server without needing to alter any other code in the client or server. > While I understand your concern, the feature is an option, not a > requirement. Yes, but it shouldn't be an option at all. You provide the option in the expectation that someone will use it. The presence of such an option therefore encourages client writers to depend on non-standard behaviors. You might say "this is a site-local policy decision" but it doesn't just affect a single site. You implicitly create lock-in with features like this, and you have no idea what other servers such clients will eventually be talking to. I would expect thinking like this from Microsoft or Sun, but not from an open source developer. And no matter how much we may think our respective server is the best in the world, and that no one would ever have any reason to talk to any other server, one need only look at SunOne to see that nothing lasts forever. Providing options that break standards like this *hurts* your users, it doesn't help them. The standard mechanism for using an LDAP session with previously established credentials is to use a SASL/EXTERNAL Bind. Encouraging any other behavior is flat out wrong. Yes, it's OK to provide options that completely change the behavior of the server. But it's only OK to do that *when the client explicitly asks for it*. I could define a control that causes all strings to be returned in Morse code, and that would be perfectly fine, because a client has to use the control before it gets such an outlandish behavior. Some folks may be wondering why I'm spending so much time on this point, since it's your server and I'm not contributing to its code. Just remember that network protocols are about interoperability; nothing you do exists in a vacuum. Every mistake anyone makes affects everyone - just look at the dynamic group mess if you need an example... -- -- 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 abartlet at samba.org Fri Feb 23 01:26:47 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 23 Feb 2007 12:26:47 +1100 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DE1145.1050403@symas.com> References: <20070222170030.D2D3673742@hormel.redhat.com> <45DE1145.1050403@symas.com> Message-ID: <1172194007.10487.202.camel@localhost.localdomain> On Thu, 2007-02-22 at 13:55 -0800, Howard Chu wrote: > > Date: Wed, 21 Feb 2007 12:16:04 -0800 > > From: Pete Rowley > > Sorry, I don't mean to beat too much on a dead horse, but ... > > > Howard Chu wrote: > >> > Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to > >> > request this privilege. There is no assumption of automagic > >> > authorization. > > > I guess we can add that. Rich and I have already talked about that as a TBD. > > > While observing RFC4513 is a good thing, and this implementation does so > > when auto-bind is switched off, I believe these kinds of decisions are > > the domain of site administrative policy and not of standards documents. > > Further, a client in the anonymous bind state has no practical knowledge > > of the effects of that state on server responses in any case, nor can it > > be sure that binding as a non-anonymous user has any effect on those > > responses, nor indeed does auto-bind necessarily remove or add any > > privilege for the client - that is all administrative policy and > > undefined by any RFC. This is just one more administrative policy option. > > Certainly it's true that LDAP has nothing specific to say about > authorization. But don't confuse authorization with authentication; they're > two separate things. A client can easily determine that it's in an anonymous > state, using the WhoAmI extended op. > > If "ldapwhoami -x -H ldapi:///" doesn't return a zero-length ID, then your > server is broken. Agreed. Now I should implement that extended operation in our server some day... > Yes, but it shouldn't be an option at all. You provide the option in the > expectation that someone will use it. The presence of such an option > therefore encourages client writers to depend on non-standard behaviors. You > might say "this is a site-local policy decision" but it doesn't just affect a > single site. You implicitly create lock-in with features like this, and you > have no idea what other servers such clients will eventually be talking to. > I would expect thinking like this from Microsoft or Sun, but not from an open > source developer. And no matter how much we may think our respective server > is the best in the world, and that no one would ever have any reason to talk > to any other server, one need only look at SunOne to see that nothing lasts > forever. Providing options that break standards like this *hurts* your users, > it doesn't help them. > > The standard mechanism for using an LDAP session with previously established > credentials is to use a SASL/EXTERNAL Bind. Encouraging any other behavior is > flat out wrong. > Some folks may be wondering why I'm spending so much time on this point, > since it's your server and I'm not contributing to its code. Just remember > that network protocols are about interoperability; nothing you do exists in a > vacuum. Every mistake anyone makes affects everyone - just look at the > dynamic group mess if you need an example... I strongly agree with Howard on this one. I want Samba to be able to bind to either OpenLDAP or Fedora DS and have as few differences as possible. And where OpenLDAP has done something first, or it's way of doing things is more sane, I ask that Fedora DS follow that lead. I need less, not more 'if ' code... (In this vane, I so wish nsUniqueID was in standard GUID format, rather than %08x-%08x-%08x-%08x...) If this needs to be made easier for client apps, then work on making setting up ldapi:// connections with an EXTERNAL bind trivial to do from the Perl Net::LDAP module and python. That will help users, no matter the LDAP server they choose to deploy. 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 Fri Feb 23 02:18:30 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 22 Feb 2007 18:18:30 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <1172194007.10487.202.camel@localhost.localdomain> References: <20070222170030.D2D3673742@hormel.redhat.com> <45DE1145.1050403@symas.com> <1172194007.10487.202.camel@localhost.localdomain> Message-ID: <45DE4EF6.1040703@redhat.com> Andrew Bartlett wrote: > And where OpenLDAP has done something first, or it's way of doing things > is more sane, I ask that Fedora DS follow that lead. I need less, not > more 'if ' code... > > Your if vendor code would be zero. Presumably Samba would be enabled with access in line with its operational requirements. Bearing in mind that Samba runs as root, it is likely to find that any machine it is installed on has anonymous access for root, just like it is allowed to actually run as root. > (In this vane, I so wish nsUniqueID was in standard GUID format, rather > than %08x-%08x-%08x-%08x...) > I believe we have already discussed this and that I have already agreed that we would look at it. -- 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 abartlet at samba.org Fri Feb 23 05:55:52 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 23 Feb 2007 16:55:52 +1100 Subject: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DA1FD0.70507@redhat.com> References: <45DA1FD0.70507@redhat.com> Message-ID: <1172210152.10487.229.camel@localhost.localdomain> On Mon, 2007-02-19 at 14:08 -0800, Pete Rowley wrote: > This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). > Heimdal uses this feature exclusively for its directory interactions (making it > incompatible with other LDAP directories), and Samba testing is often performed > over unix domain sockets (a convenience for them). There are advantages: no TCP > overhead for local connections, the ability to test for the OS level user > credentials, and AFAIK, an unsniffable transport without additional > requirements. On that last point, I welcome arguments to the contrary. > > The socket file is created as var/run/fedora-ds/slapd-.socket by > default, but this can be modified in configuration. I'm actually not sure where > the best place to put this is since access control along the path to the socket > matters. The socket itself is chmodded to give rw to owner, groups, and other by > the server upon creation. How do I change this location? What are the configuration parameters? It seems to be: + fprintf(f, "nsslapd-ldapifilepath: %s/%s-%s.socket\n", cf->run_dir, PRODUCT_NAME, cf->servid); + fprintf(f, "nsslapd-ldapilisten: on\n"); + fprintf(f, "nsslapd-ldapiautobind: on\n"); But some clarification would be useful. 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 abartlet at samba.org Fri Feb 23 05:58:39 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 23 Feb 2007 16:58:39 +1100 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DE4EF6.1040703@redhat.com> References: <20070222170030.D2D3673742@hormel.redhat.com> <45DE1145.1050403@symas.com> <1172194007.10487.202.camel@localhost.localdomain> <45DE4EF6.1040703@redhat.com> Message-ID: <1172210319.10487.233.camel@localhost.localdomain> On Thu, 2007-02-22 at 18:18 -0800, Pete Rowley wrote: > Andrew Bartlett wrote: > > And where OpenLDAP has done something first, or it's way of doing things > > is more sane, I ask that Fedora DS follow that lead. I need less, not > > more 'if ' code... > > > > > Your if vendor code would be zero. Presumably Samba would be enabled > with access in line with its operational requirements. Bearing in mind > that Samba runs as root, it is likely to find that any machine it is > installed on has anonymous access for root, just like it is allowed to > actually run as root. I'm not quite sure what you mean here, but what I don't want is a situation where the admin runs Samba4 against a Fedora DS instance, and forgets to explicitly set 'nsslapd-ldapiautobind: off'. Samba would end up proxying anonymous access as root! It certainly seems an odd default. Or worse still, there be a disagreement between applications as to if this is a setting they want, or a setting they don't want. Instead, have applications that want EXTERNAL auth ask for it, just as they have to ask for it for OpenLDAP. 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 abartlet at samba.org Fri Feb 23 06:49:35 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 23 Feb 2007 17:49:35 +1100 Subject: [Fedora-directory-devel] 'make check' or 'make test' for fedora DS? Message-ID: <1172213375.10487.248.camel@localhost.localdomain> Would it be possible to have some kind of self-test infrastructure in Fedora DS? I've grabbed current CVS, and am having some troubles running it. But I can't tell if it's just the way I'm running it, or if the current codes doesn't currently work on my machine. What I would really like is for 'make check' to be more than a stub. As fedora DS already depends on LDAP client bits, would it be too hard to use the new ldapi:// work to setup fedora DS in a private environment, and check a few things over (searches, binds, etc)? This would also nicely solve some of the 'how do I' problems I have with the ldapi:// patch (that is, it seems to still want an external port to bind to, and I need to specify some details for the socket that ds_newinst.pl doesn't know about). We have had very good results with our 'make test' in Samba4, and likewise I've seen Heimdal grow with it's testsuite (to the extent, that Love's work has become almost entirely test driven development). Naturally, it would also make it easier for external contributors to validate their changes. Thanks, 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 abartlet at samba.org Fri Feb 23 11:41:06 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 23 Feb 2007 22:41:06 +1100 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds Message-ID: <1172230867.10487.271.camel@localhost.localdomain> In working to have the Samba4 test environment configure fedora-ds. I'm using ds_newinst.pl, but it starts the DS once it is created. According to that script, I could modify it, but: # if for some reason you do not want the server started after instance creation # the following line can be commented out - NOTE that if you are creating the # Configuration DS, it will be started anyway $cgiargs{start_server} = 1; As I understand it, a new standalone install will create the configuration DS. Aside from wanting a separate configure/start sequence, I would like to be able to modify the dse.ldif to fix up some parameters, and redo the schema, before the slapd process starts. For the parameter modification, another option might be to have a 'modify ldif' in addition to the 'initial ldif', but I still need a way to clean out the schema. Thoughts? 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 Fri Feb 23 15:49:58 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 23 Feb 2007 08:49:58 -0700 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <1172230867.10487.271.camel@localhost.localdomain> References: <1172230867.10487.271.camel@localhost.localdomain> Message-ID: <45DF0D26.2060508@redhat.com> Andrew Bartlett wrote: > In working to have the Samba4 test environment configure fedora-ds. I'm > using ds_newinst.pl, but it starts the DS once it is created. > > According to that script, I could modify it, but: > > # if for some reason you do not want the server started after instance > creation > # the following line can be commented out - NOTE that if you are > creating the > # Configuration DS, it will be started anyway > $cgiargs{start_server} = 1; > > As I understand it, a new standalone install will create the > configuration DS. > No, it won't. I'm going to add a start_server option to the .inf file so you won't have to hack ds_newinst.pl anymore. Is it a problem that the server is started as a consequence of creating the instance? > Aside from wanting a separate configure/start sequence, I would like to > be able to modify the dse.ldif to fix up some parameters, and redo the > schema, before the slapd process starts. > You could do all of this with ldapmodify after the server starts, but . . . > For the parameter modification, another option might be to have a > 'modify ldif' in addition to the 'initial ldif', but I still need a way > to clean out the schema. > . . . this would be quite hard to do with the existing .inf file + ds_newinst.pl + ds_newinst (binary). The intention of ds_newinst.pl was to just convert the .inf file format into the format used by the ds_newinst binary (C code) which has a lot of code shared with ds_create which is used to do a lot of admin server/console related stuff, in addition to configuring the instance. > Thoughts? > I understand where you are coming from. With openldap, you just have to provide your own hand tuned slapd.conf file - nothing else really is required. That also controls what schema is loaded. It's not so easy to do the same thing with fedora ds. For starters, the dse.ldif file is much more complex (but in your case, there are only a few options required to be tweaked). And the schema handling (i.e. include /path/to/core.schema ; include /path/to/posix.schema) is completely out of band with this process (well, not quite - you can override the nsslapd-schemadir in cn=config). So how would you like for this to work? What would be easiest for you? > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Feb 23 17:46:45 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 23 Feb 2007 10:46:45 -0700 Subject: [Fedora-directory-devel] Please review: Bug 229825: aci with bogus uid= dn created by ds_newinst Message-ID: <45DF2885.1050108@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229825 Resolves: bug 229825 Bug Description: aci with bogus uid= dn created by ds_newinst Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Unknown to me until just now, PL_strdup(NULL) will return "" - the empty string. The code in config_suitespot() expects that empty or unused fields are NULL. The solution is to create a create_instance_strdup() wrapper around PL_strdup() and use that in cases where the argument may be NULL. I checked create_instance.c. Every other place where PL_strdup is used, the argument is checked for NULL first. So these are the only places affected. Instance creation works fine after this change and does not create the offending aci. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148687&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 prowley at redhat.com Fri Feb 23 18:24:40 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 23 Feb 2007 10:24:40 -0800 Subject: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <1172210152.10487.229.camel@localhost.localdomain> References: <45DA1FD0.70507@redhat.com> <1172210152.10487.229.camel@localhost.localdomain> Message-ID: <45DF3168.9000802@redhat.com> Andrew Bartlett wrote: > On Mon, 2007-02-19 at 14:08 -0800, Pete Rowley wrote: > >> This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). >> Heimdal uses this feature exclusively for its directory interactions (making it >> incompatible with other LDAP directories), and Samba testing is often performed >> over unix domain sockets (a convenience for them). There are advantages: no TCP >> overhead for local connections, the ability to test for the OS level user >> credentials, and AFAIK, an unsniffable transport without additional >> requirements. On that last point, I welcome arguments to the contrary. >> >> The socket file is created as var/run/fedora-ds/slapd-.socket by >> default, but this can be modified in configuration. I'm actually not sure where >> the best place to put this is since access control along the path to the socket >> matters. The socket itself is chmodded to give rw to owner, groups, and other by >> the server upon creation. >> > > How do I change this location? What are the configuration parameters? > > It seems to be: > + fprintf(f, "nsslapd-ldapifilepath: %s/%s-%s.socket\n", cf->run_dir, > PRODUCT_NAME, cf->servid); > + fprintf(f, "nsslapd-ldapilisten: on\n"); > + fprintf(f, "nsslapd-ldapiautobind: on\n"); > > But some clarification would be useful. > > Those attributes are set in the cn=config entry, ldapsearch -x -D "cn=Directory Manager" -w yourpasswd -b "cn=config" -s base "(objectclass=*)" You can modify them over ldap. nsslapd-ldapifilepath = full path of socket file nsslapd-ldapilisten = off/on to actually do ldapi at all nsslapd-ldapiautobind = off/on enforce OS authentication -- 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 prowley at redhat.com Fri Feb 23 18:43:24 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 23 Feb 2007 10:43:24 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <45DE1145.1050403@symas.com> References: <20070222170030.D2D3673742@hormel.redhat.com> <45DE1145.1050403@symas.com> Message-ID: <45DF35CC.5030006@redhat.com> Howard Chu wrote: >> Date: Wed, 21 Feb 2007 12:16:04 -0800 > > From: Pete Rowley > > Sorry, I don't mean to beat too much on a dead horse, but ... > ;) OK. That is a pretty powerful argument, and my rereading of the RFCs reveals that there is about zero wiggle room on this precise point. However, for us this is an experimental feature on top of an experimental feature (ldapi itself), and in that light I propose to do the following: 1. #ifdef WITH_AUTOBIND the auto bind code 2. not #define WITH_AUTOBIND 3. offer no configure mechanism for turning on autobind This allows experimenters to do their experimenting but requires an unusual step (in an autotools world) on the part of builders to add the feature, and it will not appear in the binary builds of FDS offered for download. Regards -- 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 rmeggins at redhat.com Fri Feb 23 18:50:46 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 23 Feb 2007 11:50:46 -0700 Subject: [Fedora-directory-devel] Please review: Bug 229077: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) Message-ID: <45DF3786.4080103@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229077 Resolves: bug 229077 Bug Description: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) Reviewed by: ??? Files: configure.ac and all generated autotool files Branch: HEAD Fix Description: We have decided to rename the new (1.1) fedora-ds to be fedora-ds-base. This reflects its actual contents since it contains only the base LDAP server and command line utilities, but not the console, admin server, webapps, etc. Those will be made available in separate packages (fedora-ds-admin, fedora-ds-console, fedora-ds-gw) and so on. This will also have a ripple effect - FHS path names will change from *fedora-ds to *fedora-ds-base - the source tarball will be fedora-ds-base-.... - even the initscript will be invoked like "service fedora-ds-base restart". The spec file and other source file changes will also follow this. Platforms tested: RHEL4, FC6 Flag Day: Yes. Any reference to fedora-ds will need to change to fedora-ds-base. Doc impact: Yes. The wiki docs will have to change any reference to fedora-ds to fedora-ds-base with respect to fds version 1.1. https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148698&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 rcritten at redhat.com Fri Feb 23 19:08:03 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Feb 2007 14:08:03 -0500 Subject: [Fedora-directory-devel] Please review: Bug 229077: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) In-Reply-To: <45DF3786.4080103@redhat.com> References: <45DF3786.4080103@redhat.com> Message-ID: <45DF3B93.7070104@redhat.com> Richard Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229077 > Resolves: bug 229077 > Bug Description: Rename fedora-ds to fedora-ds-base (The package breaks > an previous installation of the Fedora DS!!) > Reviewed by: ??? > Files: configure.ac and all generated autotool files > Branch: HEAD > Fix Description: We have decided to rename the new (1.1) fedora-ds to be > fedora-ds-base. This reflects its actual contents since it contains > only the base LDAP server and command line utilities, but not the > console, admin server, webapps, etc. Those will be made available in > separate packages (fedora-ds-admin, fedora-ds-console, fedora-ds-gw) and > so on. > This will also have a ripple effect - FHS path names will change from > *fedora-ds to *fedora-ds-base - the source tarball will be > fedora-ds-base-.... - even the initscript will be invoked like "service > fedora-ds-base restart". The spec file and other source file changes > will also follow this. > Platforms tested: RHEL4, FC6 > Flag Day: Yes. Any reference to fedora-ds will need to change to > fedora-ds-base. > Doc impact: Yes. The wiki docs will have to change any reference to > fedora-ds to fedora-ds-base with respect to fds version 1.1. > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148698&action=diff > Do you really need the init script to be fedora-ds-base? There shouldn't be a conflict calling it fedora-ds. 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 rmeggins at redhat.com Fri Feb 23 19:16:34 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 23 Feb 2007 12:16:34 -0700 Subject: [Fedora-directory-devel] Please review: Bug 229077: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) In-Reply-To: <45DF3B93.7070104@redhat.com> References: <45DF3786.4080103@redhat.com> <45DF3B93.7070104@redhat.com> Message-ID: <45DF3D92.6060609@redhat.com> Rob Crittenden wrote: > Richard Megginson wrote: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229077 >> Resolves: bug 229077 >> Bug Description: Rename fedora-ds to fedora-ds-base (The package >> breaks an previous installation of the Fedora DS!!) >> Reviewed by: ??? >> Files: configure.ac and all generated autotool files >> Branch: HEAD >> Fix Description: We have decided to rename the new (1.1) fedora-ds to >> be fedora-ds-base. This reflects its actual contents since it >> contains only the base LDAP server and command line utilities, but >> not the console, admin server, webapps, etc. Those will be made >> available in separate packages (fedora-ds-admin, fedora-ds-console, >> fedora-ds-gw) and so on. >> This will also have a ripple effect - FHS path names will change from >> *fedora-ds to *fedora-ds-base - the source tarball will be >> fedora-ds-base-.... - even the initscript will be invoked like >> "service fedora-ds-base restart". The spec file and other source >> file changes will also follow this. >> Platforms tested: RHEL4, FC6 >> Flag Day: Yes. Any reference to fedora-ds will need to change to >> fedora-ds-base. >> Doc impact: Yes. The wiki docs will have to change any reference to >> fedora-ds to fedora-ds-base with respect to fds version 1.1. >> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148698&action=diff >> >> > > Do you really need the init script to be fedora-ds-base? There > shouldn't be a conflict calling it fedora-ds. There is no conflict, as such. There is no conflict with path naming either - it makes no difference if it's named /etc/fedora-ds or /etc/fedora-ds-base for example. The thing is that, in the Linux Way (tm) of doing things, if you have a package named pkgname you have to use pkgname in path naming e.g. /etc/$pkgname, /var/lib/$pkgname, and so on. If the pkg is a network service, you have to be able to say service $pkgname restart, etc. > > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Feb 23 19:28:26 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 23 Feb 2007 12:28:26 -0700 Subject: [Fedora-directory-devel] Redux: Please review: Bug 229077: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) Message-ID: <45DF405A.3060406@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229077 Resolves: bug 229077 Bug Description: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) Reviewed by: ??? Files: configure.ac and all generated autotool files Branch: HEAD Fix Description: As it turns out, only the spec file will have to change. It is ok that we have a package named pkgname-base that uses paths like /etc/pkgname and service pkgname. So this diff has been revised to simply bump the version in the code to differentiate it from the previously withdrawn fedora-ds in Fedora Extras. Platforms tested: RHEL4, FC6 Flag Day: No. Doc impact: No. https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c5 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file:///tmp/nsmail-1.tmp URL: -------------- 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 prowley at redhat.com Fri Feb 23 21:32:58 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 23 Feb 2007 13:32:58 -0800 Subject: [Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets) In-Reply-To: <1172210319.10487.233.camel@localhost.localdomain> References: <20070222170030.D2D3673742@hormel.redhat.com> <45DE1145.1050403@symas.com> <1172194007.10487.202.camel@localhost.localdomain> <45DE4EF6.1040703@redhat.com> <1172210319.10487.233.camel@localhost.localdomain> Message-ID: <45DF5D8A.9080404@redhat.com> Andrew Bartlett wrote: > On Thu, 2007-02-22 at 18:18 -0800, Pete Rowley wrote: > >> Andrew Bartlett wrote: >> >>> And where OpenLDAP has done something first, or it's way of doing things >>> is more sane, I ask that Fedora DS follow that lead. I need less, not >>> more 'if ' code... >>> >>> >>> >> Your if vendor code would be zero. Presumably Samba would be enabled >> with access in line with its operational requirements. Bearing in mind >> that Samba runs as root, it is likely to find that any machine it is >> installed on has anonymous access for root, just like it is allowed to >> actually run as root. >> > > I'm not quite sure what you mean here, I mean typically services are not allowed to run as root, but apparently Samba must so Samba is configured to do so if the site needs Samba. In exactly the same way, as an example only, auto bind for root might be often mapped to some administrative user in the directory, but clearly that would not be desirable if one wanted Samba to run on the machine. Options would then be: don't configure root as anything other than anonymous, or, if that was not acceptable, configure samba to use LDAP, not LDAPI, or configure samba to have root OS privilege, but make use of the autobind feature that allows to more finely distinguish between OS users with the same uid and have Samba identified by its own unique entry with its own unique security context. None of those options involve an #ifdef vendor or even the slightest whiff of a branch in your code. > It certainly seems an odd default. > > Agreed, but that is moot at this point. -- 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 abartlet at samba.org Fri Feb 23 21:49:45 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 24 Feb 2007 08:49:45 +1100 Subject: [Fedora-directory-devel] Redux: Please review: Bug 229077: Rename fedora-ds to fedora-ds-base (The package breaks an previous installation of the Fedora DS!!) In-Reply-To: <45DF405A.3060406@redhat.com> References: <45DF405A.3060406@redhat.com> Message-ID: <1172267385.10487.282.camel@localhost.localdomain> On Fri, 2007-02-23 at 12:28 -0700, Richard Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229077 > Resolves: bug 229077 > Bug Description: Rename fedora-ds to fedora-ds-base (The package breaks > an previous installation of the Fedora DS!!) > Reviewed by: ??? > Files: configure.ac and all generated autotool files > Branch: HEAD > Fix Description: As it turns out, only the spec file will have to > change. It is ok that we have a package named pkgname-base that uses > paths like /etc/pkgname and service pkgname. So this diff has been > revised to simply bump the version in the code to differentiate it from > the previously withdrawn fedora-ds in Fedora Extras. > Platforms tested: RHEL4, FC6 This seems much more sensible... 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 abartlet at samba.org Fri Feb 23 22:02:23 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 24 Feb 2007 09:02:23 +1100 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <45DF0D26.2060508@redhat.com> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> Message-ID: <1172268143.10487.291.camel@localhost.localdomain> On Fri, 2007-02-23 at 08:49 -0700, Richard Megginson wrote: > Andrew Bartlett wrote: > > In working to have the Samba4 test environment configure fedora-ds. I'm > > using ds_newinst.pl, but it starts the DS once it is created. > > > > According to that script, I could modify it, but: > > > > # if for some reason you do not want the server started after instance > > creation > > # the following line can be commented out - NOTE that if you are > > creating the > > # Configuration DS, it will be started anyway > > $cgiargs{start_server} = 1; > > > > As I understand it, a new standalone install will create the > > configuration DS. > > > No, it won't. > > I'm going to add a start_server option to the .inf file so you won't > have to hack ds_newinst.pl anymore. Thanks > Is it a problem that the server is started as a consequence of creating > the instance? > > Aside from wanting a separate configure/start sequence, I would like to > > be able to modify the dse.ldif to fix up some parameters, and redo the > > schema, before the slapd process starts. > > > You could do all of this with ldapmodify after the server starts, but . . . > > For the parameter modification, another option might be to have a > > 'modify ldif' in addition to the 'initial ldif', but I still need a way > > to clean out the schema. > > > . . . this would be quite hard to do with the existing .inf file + > ds_newinst.pl + ds_newinst (binary). The intention of ds_newinst.pl was > to just convert the .inf file format into the format used by the > ds_newinst binary (C code) which has a lot of code shared with ds_create > which is used to do a lot of admin server/console related stuff, in > addition to configuring the instance. > > Thoughts? > > > I understand where you are coming from. With openldap, you just have to > provide your own hand tuned slapd.conf file - nothing else really is > required. That also controls what schema is loaded. Yeah. It really does show that I did this on OpenLDAP first... > It's not so easy to do the same thing with fedora ds. For starters, the > dse.ldif file is much more complex (but in your case, there are only a > few options required to be tweaked). And the schema handling (i.e. > include /path/to/core.schema ; include /path/to/posix.schema) is > completely out of band with this process (well, not quite - you can > override the nsslapd-schemadir in cn=config). So, yes, I suppose I'm just trying to turn Fedora DS into OpenLDAP, one step at a time :-) > So how would you like for this to work? What would be easiest for you? A few things would be useful: Firstly, for the path to the ldapi socket to be part of the inf file, so I can make it identical between the two supported servers (just makes my life easier). If I can't get that, then I need to be able to modify the dse.inf before it starts. Slightly adjunct to this, i need a way to prevent the DS from binding to anything except the unix domain socket (for security). ie, no IPv4 ports. For the ds to be configured, but not started, so I can can copy out the default schema, and replace it with just the core schema, and samba4's schema. Once I do all that, I would like to start the server for the first time, knowing I've got full control over it's parameters. 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 Fri Feb 23 22:28:53 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 23 Feb 2007 14:28:53 -0800 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <1172268143.10487.291.camel@localhost.localdomain> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> Message-ID: <45DF6AA5.5030505@redhat.com> Andrew Bartlett wrote: > Slightly adjunct to this, i need a way to prevent the DS from binding to > anything except the unix domain socket (for security). ie, no IPv4 > ports. > You _should_ be able to do this by specifying port 0 -- 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 eswars at huawei.com Sat Feb 24 07:11:23 2007 From: eswars at huawei.com (Eswar S) Date: Sat, 24 Feb 2007 12:41:23 +0530 Subject: [Fedora-directory-devel] (no subject) Message-ID: <001201c757e2$fdf78130$0c12120a@china.huawei.com> Hi all, I can please tell me , how to tune fedora 7.1 for good Performance. Now it is taking 20,000 records in 4.15 sec using ldapmodify command. >From console import it is around 2min .30 sec. Is there any statistic information for fedora-ds performance? Please tell some configuration setting that can improve performance .. Thanks Eswar s **************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyc at symas.com Sat Feb 24 18:42:29 2007 From: hyc at symas.com (Howard Chu) Date: Sat, 24 Feb 2007 10:42:29 -0800 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <20070224170023.18E8273408@hormel.redhat.com> References: <20070224170023.18E8273408@hormel.redhat.com> Message-ID: <45E08715.6090108@symas.com> > Date: Sat, 24 Feb 2007 09:02:23 +1100 > From: Andrew Bartlett > On Fri, 2007-02-23 at 08:49 -0700, Richard Megginson wrote: >> > Andrew Bartlett wrote: >> > I understand where you are coming from. With openldap, you just have to >> > provide your own hand tuned slapd.conf file - nothing else really is >> > required. That also controls what schema is loaded. > Yeah. It really does show that I did this on OpenLDAP first... >> > It's not so easy to do the same thing with fedora ds. For starters, the >> > dse.ldif file is much more complex (but in your case, there are only a >> > few options required to be tweaked). And the schema handling (i.e. >> > include /path/to/core.schema ; include /path/to/posix.schema) is >> > completely out of band with this process (well, not quite - you can >> > override the nsslapd-schemadir in cn=config). > So, yes, I suppose I'm just trying to turn Fedora DS into OpenLDAP, one > step at a time :-) Good man! ;) (But wait, I thought we were turning OpenLDAP's config into ... oh never mind...) I don't know if this will help you guys or not, but we implemented "include:" directives for LDIF, following this discussion: http://www.openldap.org/lists/ietf-ldapext/200504/msg00003.html The current manpage also describes it http://www.openldap.org/software/man.cgi?query=ldif&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release Note that this is already implemented in OpenLDAP 2.3, we just didn't backport the manpage update (oops). Anyway, this lets us create very compact config.ldif's that can be slapadd'd to bootstrap a server, with all relevant schema (in LDIF, not slapd.conf format) referenced as desired. Obviously being able to keep everything under a single config tree makes life a lot easier. -- -- 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 abartlet at samba.org Mon Feb 26 03:42:08 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 26 Feb 2007 14:42:08 +1100 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <45DF6AA5.5030505@redhat.com> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45DF6AA5.5030505@redhat.com> Message-ID: <1172461328.6964.0.camel@localhost.localdomain> On Fri, 2007-02-23 at 14:28 -0800, Pete Rowley wrote: > Andrew Bartlett wrote: > > Slightly adjunct to this, i need a way to prevent the DS from binding to > > anything except the unix domain socket (for security). ie, no IPv4 > > ports. > > > You _should_ be able to do this by specifying port 0 Nope, doesn't work (at least for ds_newisnt.pl). 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 abartlet at samba.org Mon Feb 26 04:02:05 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 26 Feb 2007 15:02:05 +1100 Subject: [Fedora-directory-devel] Very slow to run dn_newinst.pl Message-ID: <1172462525.6964.4.camel@localhost.localdomain> It seems to me that ds_newinst.pl takes a very long time, particularly in various DNS challenged environments. (I presume this is DNS, from earlier hints and because of the length of the timeout) As this should be an automated, scripted process in a tight reproducible testing environment, I'm trying to avoid it doing anything that would cause actual network packets. Is there anything else that could cause ds_newinst.pl to appear to hang? Is there a way to ensure it never does DNS queries? Thanks, 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 abartlet at samba.org Mon Feb 26 05:20:15 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 26 Feb 2007 16:20:15 +1100 Subject: [Fedora-directory-devel] Can't start Fedora DS in test env Message-ID: <1172467215.6964.8.camel@localhost.localdomain> I'm having trouble starting Fedora Directory... In my further attempts to run FDS in my Samba4 test environment, using current CVS, I get the following: Fedora-Directory/1.1.0a1 B2007.054.711 : (/data/samba/samba4/svn/source/st/ldap/slapd-samba4) [26/Feb/2007:15:21:31 +1100] - slapi_str2entry: entry has multiple dns "cn=Distributed Numeric Assignment Plugin,cn=plugins,c n=config" and "cn=ldbm database,cn=plugins,cn=config" (second ignored) [26/Feb/2007:15:21:32 +1100] - slapi_str2entry: entry has multiple dns "cn=Distributed Numeric Assignment Plugin,cn=plugins,c n=config" and "cn=ldbm database,cn=plugins,cn=config" (second ignored) [26/Feb/2007:15:21:32 +1100] - 3 duplicate values for attribute type objectclass detected in entry cn=Distributed Numeric Ass ignment Plugin,cn=plugins,cn=config. Extra values ignored. [26/Feb/2007:15:21:32 +1100] - Fedora-Directory/1.1.0a1 B2007.054.711 starting up [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for dc=samba,dc=example,dc=com point to an unknown backend : userRoot [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for dc=samba,dc=example,dc=com point to an unknown backend : userRoot [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for dc=samba,dc=example,dc=com point to an unknown backend : userRoot [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for dc=samba,dc=example,dc=com point to an unknown backend : userRoot [26/Feb/2007:15:21:32 +1100] - Error: Failed to resolve plugin dependencies [26/Feb/2007:15:21:32 +1100] - Error: object plugin Legacy Replication Plugin is not started [26/Feb/2007:15:21:32 +1100] - Error: object plugin Multimaster Replication Plugin is not started -- 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 eswars at huawei.com Mon Feb 26 08:59:20 2007 From: eswars at huawei.com (Eswar S) Date: Mon, 26 Feb 2007 14:29:20 +0530 Subject: [Fedora-directory-devel] RE: Fedora-directory-devel Digest, Vol 20, Issue 17 In-Reply-To: <20070225170016.035B8734B4@hormel.redhat.com> Message-ID: <003501c75984$67ce0aa0$0c12120a@china.huawei.com> Hi, How to configure Fedora-ds for other RDBMS databases. Currently I have lbdm database like cn = lbdm database cn=plugins,cn=config If I want PostgresSQL as backend , how can I configure. Please help for this. Thank you Eswar S From eswars at huawei.com Mon Feb 26 09:09:13 2007 From: eswars at huawei.com (Eswar S) Date: Mon, 26 Feb 2007 14:39:13 +0530 Subject: [Fedora-directory-devel] fedora-ds performance report In-Reply-To: <20070224170023.18E8273408@hormel.redhat.com> Message-ID: <003901c75985$c95f58e0$0c12120a@china.huawei.com> Hi all, I can please tell me , how to tune fedora 7.1 for good Performance. Now it is taking 20,000 records in 4.15 sec using ldapmodify command. >From console import it is around 2min .30 sec. Is there any statistic information for fedora-ds performance? Please tell some configuration setting that can improve performance .. Thanks Eswar s **************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From rmeggins at redhat.com Mon Feb 26 14:15:13 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 26 Feb 2007 07:15:13 -0700 Subject: [Fedora-directory-devel] RE: Fedora-directory-devel Digest, Vol 20, Issue 17 In-Reply-To: <003501c75984$67ce0aa0$0c12120a@china.huawei.com> References: <003501c75984$67ce0aa0$0c12120a@china.huawei.com> Message-ID: <45E2EB71.6050405@redhat.com> Eswar S wrote: > Hi, > > How to configure Fedora-ds for other RDBMS databases. Currently I > have lbdm database like cn = lbdm database cn=plugins,cn=config > If I want PostgresSQL as backend , how can I configure. > Please help for this. > http://directory.fedora.redhat.com/wiki/FAQ#Can_I_replace_Sleepycat_with_Oracle.2C_or_Postgres.2C_etc..3F > Thank you > Eswar S > > > > -- > 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 rmeggins at redhat.com Mon Feb 26 14:45:42 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 26 Feb 2007 07:45:42 -0700 Subject: [Fedora-directory-devel] Can't start Fedora DS in test env In-Reply-To: <1172467215.6964.8.camel@localhost.localdomain> References: <1172467215.6964.8.camel@localhost.localdomain> Message-ID: <45E2F296.7000702@redhat.com> Andrew Bartlett wrote: > I'm having trouble starting Fedora Directory... > In my further attempts to run FDS in my Samba4 test environment, using > current CVS, I get the following: > > Fedora-Directory/1.1.0a1 B2007.054.711 > : > (/data/samba/samba4/svn/source/st/ldap/slapd-samba4) > > [26/Feb/2007:15:21:31 +1100] - slapi_str2entry: entry has multiple dns > "cn=Distributed Numeric Assignment Plugin,cn=plugins,c > n=config" and "cn=ldbm database,cn=plugins,cn=config" (second ignored) > This must not be current CVS because I fixed this on Friday. https://www.redhat.com/archives/fedora-directory-commits/2007-February/date.html 23 February 2007 > [26/Feb/2007:15:21:32 +1100] - slapi_str2entry: entry has multiple dns > "cn=Distributed Numeric Assignment Plugin,cn=plugins,c > n=config" and "cn=ldbm database,cn=plugins,cn=config" (second ignored) > [26/Feb/2007:15:21:32 +1100] - 3 duplicate values for attribute type > objectclass detected in entry cn=Distributed Numeric Ass > ignment Plugin,cn=plugins,cn=config. Extra values ignored. > [26/Feb/2007:15:21:32 +1100] - Fedora-Directory/1.1.0a1 B2007.054.711 > starting up > [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for > dc=samba,dc=example,dc=com point to an unknown backend : > userRoot > [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for > dc=samba,dc=example,dc=com point to an unknown backend : > userRoot > [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for > dc=samba,dc=example,dc=com point to an unknown backend : > userRoot > [26/Feb/2007:15:21:32 +1100] - Warning: Mapping tree node entry for > dc=samba,dc=example,dc=com point to an unknown backend : > userRoot > [26/Feb/2007:15:21:32 +1100] - Error: Failed to resolve plugin > dependencies > [26/Feb/2007:15:21:32 +1100] - Error: object plugin Legacy Replication > Plugin is not started > [26/Feb/2007:15:21:32 +1100] - Error: object plugin Multimaster > Replication Plugin is not started > > > ------------------------------------------------------------------------ > > -- > 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 prowley at redhat.com Mon Feb 26 19:10:14 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 26 Feb 2007 11:10:14 -0800 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <1172461328.6964.0.camel@localhost.localdomain> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45DF6AA5.5030505@redhat.com> <1172461328.6964.0.camel@localhost.localdomain> Message-ID: <45E33096.50204@redhat.com> Andrew Bartlett wrote: > On Fri, 2007-02-23 at 14:28 -0800, Pete Rowley wrote: > >> Andrew Bartlett wrote: >> >>> Slightly adjunct to this, i need a way to prevent the DS from binding to >>> anything except the unix domain socket (for security). ie, no IPv4 >>> ports. >>> >>> >> You _should_ be able to do this by specifying port 0 >> > > Nope, doesn't work (at least for ds_newisnt.pl). > > How does it fail? Logs? Note you'll need at least one transport. -- 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 abartlet at samba.org Mon Feb 26 20:42:31 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 27 Feb 2007 07:42:31 +1100 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <45E33096.50204@redhat.com> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45DF6AA5.5030505@redhat.com> <1172461328.6964.0.camel@localhost.localdomain> <45E33096.50204@redhat.com> Message-ID: <1172522551.21804.1.camel@localhost.localdomain> On Mon, 2007-02-26 at 11:10 -0800, Pete Rowley wrote: > Andrew Bartlett wrote: > > On Fri, 2007-02-23 at 14:28 -0800, Pete Rowley wrote: > > > >> Andrew Bartlett wrote: > >> > >>> Slightly adjunct to this, i need a way to prevent the DS from binding to > >>> anything except the unix domain socket (for security). ie, no IPv4 > >>> ports. > >>> > >>> > >> You _should_ be able to do this by specifying port 0 > >> > > > > Nope, doesn't work (at least for ds_newisnt.pl). > > > > > How does it fail? Logs? Sorry, I know better than to be like that. ds_newinst.pl thinks that the required parameter (ServerPort) isn't specified when it is set to 0. > Note you'll need at least one transport. That I hoped would be ldapi:// 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 Mon Feb 26 22:50:56 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 26 Feb 2007 14:50:56 -0800 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <1172522551.21804.1.camel@localhost.localdomain> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45DF6AA5.5030505@redhat.com> <1172461328.6964.0.camel@localhost.localdomain> <45E33096.50204@redhat.com> <1172522551.21804.1.camel@localhost.localdomain> Message-ID: <45E36450.7080600@redhat.com> Andrew Bartlett wrote: > On Mon, 2007-02-26 at 11:10 -0800, Pete Rowley wrote: > >> Andrew Bartlett wrote: >> >>> On Fri, 2007-02-23 at 14:28 -0800, Pete Rowley wrote: >>> >>> >>>> Andrew Bartlett wrote: >>>> >>>> >>>>> Slightly adjunct to this, i need a way to prevent the DS from binding to >>>>> anything except the unix domain socket (for security). ie, no IPv4 >>>>> ports. >>>>> >>>>> >>>>> >>>> You _should_ be able to do this by specifying port 0 >>>> >>>> >>> Nope, doesn't work (at least for ds_newisnt.pl). >>> >>> >>> >> How does it fail? Logs? >> > > Sorry, I know better than to be like that. ds_newinst.pl thinks that > the required parameter (ServerPort) isn't specified when it is set to 0. > > Ah ok, try setting it to 0 via ldap then do a server restart - lets see if at least the server is behaving. >> Note you'll need at least one transport. >> > > That I hoped would be ldapi:// > me too > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- 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 abartlet at samba.org Tue Feb 27 01:10:43 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 27 Feb 2007 12:10:43 +1100 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <45E36450.7080600@redhat.com> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45DF6AA5.5030505@redhat.com> <1172461328.6964.0.camel@localhost.localdomain> <45E33096.50204@redhat.com> <1172522551.21804.1.camel@localhost.localdomain> <45E36450.7080600@redhat.com> Message-ID: <1172538643.3322.3.camel@localhost.localdomain> On Mon, 2007-02-26 at 14:50 -0800, Pete Rowley wrote: > Andrew Bartlett wrote: > > On Mon, 2007-02-26 at 11:10 -0800, Pete Rowley wrote: > > > >> Andrew Bartlett wrote: > >> > >>> On Fri, 2007-02-23 at 14:28 -0800, Pete Rowley wrote: > >>> > >>> > >>>> Andrew Bartlett wrote: > >>>> > >>>> > >>>>> Slightly adjunct to this, i need a way to prevent the DS from binding to > >>>>> anything except the unix domain socket (for security). ie, no IPv4 > >>>>> ports. > >>>>> > >>>>> > >>>>> > >>>> You _should_ be able to do this by specifying port 0 > >>>> > >>>> > >>> Nope, doesn't work (at least for ds_newisnt.pl). > >>> > >>> > >>> > >> How does it fail? Logs? > >> > > > > Sorry, I know better than to be like that. ds_newinst.pl thinks that > > the required parameter (ServerPort) isn't specified when it is set to 0. > > > > > Ah ok, try setting it to 0 via ldap then do a server restart - lets see > if at least the server is behaving. It doesn't seem to work: Editing dse.ldif manually to set a 0 port, I now get: (console) [27/Feb/2007:12:08:19 +1100] - Information: Non-Secure Port Disabled, server only contactable via secure port Server failed to start !!! Please check errors log for problems (logs) [27/Feb/2007:12:08:19 +1100] - Information: Non-Secure Port Disabled, server only contactable via secure port [27/Feb/2007:12:08:20 +1100] - Fedora-Directory/1.1.0a2 B2007.055.926 starting up -- 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 Tue Feb 27 21:11:24 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 27 Feb 2007 14:11:24 -0700 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <1172268143.10487.291.camel@localhost.localdomain> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> Message-ID: <45E49E7C.10708@redhat.com> Andrew Bartlett wrote: > > A few things would be useful: > > Firstly, for the path to the ldapi socket to be part of the inf file, so > I can make it identical between the two supported servers (just makes my > life easier). > > If I can't get that, then I need to be able to modify the dse.inf before > it starts. > > Slightly adjunct to this, i need a way to prevent the DS from binding to > anything except the unix domain socket (for security). ie, no IPv4 > ports. > > For the ds to be configured, but not started, so I can can copy out the > default schema, and replace it with just the core schema, and samba4's > schema. > ds_newinst requires the server to be started to add the default acis in cn=config, cn=schema, cn=monitor and elsewhere. So if the server is not started by ds_newinst, these acis will not be present, and the server will have no access except for read only access to the root DSE. Is this ok? > Once I do all that, I would like to start the server for the first time, > knowing I've got full control over it's parameters. > > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mvheukelom at van-boxtel-software.nl Wed Feb 28 09:30:45 2007 From: mvheukelom at van-boxtel-software.nl (Michiel van Heukelom - Van Boxtel Software BV) Date: Wed, 28 Feb 2007 10:30:45 +0100 Subject: [Fedora-directory-devel] LDAP Authentication Message-ID: <000a01c75b1b$1fedef00$800101df@vbs.local> Problem with authenticate. I've installed fedora-ds-1.0.4-1.RHEL4.i386.opt.rpm and it seems to be working fine. I can manage users by the console. On another machine i want to use the directory, but when ik log in, in /var/log/messages i get the following error: Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: check pass; user unknown Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: authentication failure; logname= uid=0 euid=0 tty=pts/2 ruser= rhost=192.168.100.176 Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: could not identify user (from getpwnam(mvheukelom)) Feb 23 13:07:59 ldap-vm4 login[3885]: User not known to the underlying authentication module On my ldap server the file /opt/fedora-ds/slapd/logs/access [28/Feb/2007:11:27:49 +0100] conn=250 op=0 BIND dn="dc=example,dc=com" method=128 version=3 [28/Feb/2007:11:27:49 +0100] conn=250 op=0 RESULT err=48 tag=97 nentries=0 etime=0 [28/Feb/2007:11:27:51 +0100] conn=251 fd=67 slot=67 connection from 192.168.100.118 to 192.168.100.119 [28/Feb/2007:11:27:51 +0100] conn=251 op=0 BIND dn="dc=example,dc=com" method=128 version=3 [28/Feb/2007:11:27:51 +0100] conn=251 op=0 RESULT err=48 tag=97 nentries=0 etime=0 [28/Feb/2007:11:27:51 +0100] conn=251 op=1 UNBIND [28/Feb/2007:11:27:51 +0100] conn=251 op=1 fd=67 closed - U1 my ldap.conf on my client: host 192.168.100.119 base dc=Example,dc=com rootbinddn dc=example,dc=com In authconfig i've made the changes to: use ladap and user ldap authentication. I've also filled in my server (IP-number) and my base. Can someone advise me what to check please.... Best regards, Michiel van Heukelom Van Boxtel Software B.V. Phone: +31 (0) 492 - 327 357 Fax: +31 (0) 492 - 324 326 E-mail: mvheukelom at van-boxtel-software.nl Website: www.van-boxtel-software.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From joona.hartman at gmail.com Wed Feb 28 15:02:32 2007 From: joona.hartman at gmail.com (J. Hartman) Date: Wed, 28 Feb 2007 17:02:32 +0200 Subject: [Fedora-directory-devel] LDAP Authentication In-Reply-To: <000a01c75b1b$1fedef00$800101df@vbs.local> References: <000a01c75b1b$1fedef00$800101df@vbs.local> Message-ID: Hi, In your client's ldap.conf, the rootbinddn should be set to a real account object, possibly the "cn=directory manager". In access log, you can see that the client is trying to bind as "dc=example,dc=com" (server's naming context!), and err=48 shows that the entry doesn't have userPassword attribute. Try commenting out the rootbinddn line or use "cn=directory manager". Regards, Joona Hartman On 2/28/07, Michiel van Heukelom - Van Boxtel Software BV < mvheukelom at van-boxtel-software.nl> wrote: > > > > Problem with authenticate. > > I've installed fedora-ds-1.0.4-1.RHEL4.i386.opt.rpm and it seems to be > working fine. I can manage users by the console. On another machine i want > to use the directory, but when ik log in, in /var/log/messages i get the > following error: > > Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: check pass; user unknown > > Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: authentication failure; > logname= uid=0 euid=0 tty=pts/2 ruser= rhost=192.168.100.176 > > Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: could not identify user > (from getpwnam(mvheukelom)) > > Feb 23 13:07:59 ldap-vm4 login[3885]: User not known to the underlying > authentication module > > On my ldap server the file /opt/fedora-ds/slapd/logs/access > > [28/Feb/2007:11:27:49 +0100] conn=250 op=0 BIND dn="dc=example,dc=com" > method=128 version=3 > [28/Feb/2007:11:27:49 +0100] conn=250 op=0 RESULT err=48 tag=97 nentries=0 > etime=0 > [28/Feb/2007:11:27:51 +0100] conn=251 fd=67 slot=67 connection from > 192.168.100.118 to 192.168.100.119 > [28/Feb/2007:11:27:51 +0100] conn=251 op=0 BIND dn="dc=example,dc=com" > method=128 version=3 > [28/Feb/2007:11:27:51 +0100] conn=251 op=0 RESULT err=48 tag=97 nentries=0 > etime=0 > [28/Feb/2007:11:27:51 +0100] conn=251 op=1 UNBIND > [28/Feb/2007:11:27:51 +0100] conn=251 op=1 fd=67 closed - U1 > > my ldap.conf on my client: > > host 192.168.100.119 > > base dc=Example,dc=com > > rootbinddn dc=example,dc=com > > In authconfig i've made the changes to: use ladap and user ldap > authentication. I've also filled in my server (IP-number) and my base. > > Can someone advise me what to check please.... > * > > > Best regards, > > Michiel van Heukelom > > Van Boxtel Software B.V. > > > > Phone: +31 (0) 492 - 327 357 Fax: +31 (0) 492 - 324 326 E-mail: > mvheukelom at van-boxtel-software.nl Website: www.van-boxtel-software.nl* > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Feb 28 15:00:16 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 28 Feb 2007 08:00:16 -0700 Subject: [Fedora-directory-devel] LDAP Authentication In-Reply-To: <000a01c75b1b$1fedef00$800101df@vbs.local> References: <000a01c75b1b$1fedef00$800101df@vbs.local> Message-ID: <45E59900.7060603@redhat.com> Michiel van Heukelom - Van Boxtel Software BV wrote: > > > Problem with authenticate. > > I've installed fedora-ds-1.0.4-1.RHEL4.i386.opt.rpm and it seems to be > working fine. I can manage users by the console. On another machine i > want to use the directory, but when ik log in, in /var/log/messages i > get the following error: > > Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: check pass; user unknown > > Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: authentication > failure; logname= uid=0 euid=0 tty=pts/2 ruser= rhost=192.168.100.176 > > Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: could not identify > user (from getpwnam(mvheukelom)) > > Feb 23 13:07:59 ldap-vm4 login[3885]: User not known to the underlying > authentication module > > On my ldap server the file /opt/fedora-ds/slapd/logs/access > > [28/Feb/2007:11:27:49 +0100] conn=250 op=0 BIND dn="dc=example,dc=com" > method=128 version=3 > [28/Feb/2007:11:27:49 +0100] conn=250 op=0 RESULT err=48 tag=97 > nentries=0 etime=0 > [28/Feb/2007:11:27:51 +0100] conn=251 fd=67 slot=67 connection from > 192.168.100.118 to 192.168.100.119 > [28/Feb/2007:11:27:51 +0100] conn=251 op=0 BIND dn="dc=example,dc=com" > method=128 version=3 > [28/Feb/2007:11:27:51 +0100] conn=251 op=0 RESULT err=48 tag=97 > nentries=0 etime=0 > [28/Feb/2007:11:27:51 +0100] conn=251 op=1 UNBIND > [28/Feb/2007:11:27:51 +0100] conn=251 op=1 fd=67 closed - U1 > > my ldap.conf on my client: > > host 192.168.100.119 > > base dc=Example,dc=com > > rootbinddn dc=example,dc=com > The rootbinddn is usually something like "cn=Directory Manager" for Fedora DS. Do you need a rootbinddn? > > In authconfig i've made the changes to: use ladap and user ldap > authentication. I've also filled in my server (IP-number) and my base. > > Can someone advise me what to check please.... > > ** > > * > Best regards,* > > *Michiel van Heukelom* > > **Van Boxtel Software B.V.** > > * * > > Phone: +31 (0) 492 - 327 357 > Fax: +31 (0) 492 - 324 326 > E-mail: mvheukelom at van-boxtel-software.nl > > Website: www.van-boxtel-software.nl > > > ------------------------------------------------------------------------ > > -- > 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 Wed Feb 28 21:40:39 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 01 Mar 2007 08:40:39 +1100 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <45E49E7C.10708@redhat.com> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45E49E7C.10708@redhat.com> Message-ID: <1172698839.21804.19.camel@localhost.localdomain> On Tue, 2007-02-27 at 14:11 -0700, Richard Megginson wrote: > Andrew Bartlett wrote: > > > > A few things would be useful: > > > > Firstly, for the path to the ldapi socket to be part of the inf file, so > > I can make it identical between the two supported servers (just makes my > > life easier). > > > > If I can't get that, then I need to be able to modify the dse.inf before > > it starts. > > > > Slightly adjunct to this, i need a way to prevent the DS from binding to > > anything except the unix domain socket (for security). ie, no IPv4 > > ports. > > > > For the ds to be configured, but not started, so I can can copy out the > > default schema, and replace it with just the core schema, and samba4's > > schema. > > > ds_newinst requires the server to be started to add the default acis in > cn=config, cn=schema, cn=monitor and elsewhere. So if the server is not > started by ds_newinst, these acis will not be present, and the server > will have no access except for read only access to the root DSE. Is > this ok? I'll live. Any progress on the other parts of this (ServerPort 0, ldapi path specification)? 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 Wed Feb 28 21:49:49 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 28 Feb 2007 14:49:49 -0700 Subject: [Fedora-directory-devel] Need to configure, but not start fedora-ds In-Reply-To: <1172698839.21804.19.camel@localhost.localdomain> References: <1172230867.10487.271.camel@localhost.localdomain> <45DF0D26.2060508@redhat.com> <1172268143.10487.291.camel@localhost.localdomain> <45E49E7C.10708@redhat.com> <1172698839.21804.19.camel@localhost.localdomain> Message-ID: <45E5F8FD.3020109@redhat.com> Andrew Bartlett wrote: > On Tue, 2007-02-27 at 14:11 -0700, Richard Megginson wrote: > >> Andrew Bartlett wrote: >> >>> >>> A few things would be useful: >>> >>> Firstly, for the path to the ldapi socket to be part of the inf file, so >>> I can make it identical between the two supported servers (just makes my >>> life easier). >>> >>> If I can't get that, then I need to be able to modify the dse.inf before >>> it starts. >>> >>> Slightly adjunct to this, i need a way to prevent the DS from binding to >>> anything except the unix domain socket (for security). ie, no IPv4 >>> ports. >>> >>> For the ds to be configured, but not started, so I can can copy out the >>> default schema, and replace it with just the core schema, and samba4's >>> schema. >>> >>> >> ds_newinst requires the server to be started to add the default acis in >> cn=config, cn=schema, cn=monitor and elsewhere. So if the server is not >> started by ds_newinst, these acis will not be present, and the server >> will have no access except for read only access to the root DSE. Is >> this ok? >> > > I'll live. Any progress on the other parts of this (ServerPort 0, ldapi > path specification)? > Yes. Testing now. > 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: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mvheukelom at van-boxtel-software.nl Wed Feb 28 15:32:49 2007 From: mvheukelom at van-boxtel-software.nl (Michiel van Heukelom - Van Boxtel Software BV) Date: Wed, 28 Feb 2007 16:32:49 +0100 Subject: [Fedora-directory-devel] LDAP Authentication References: <000a01c75b1b$1fedef00$800101df@vbs.local> Message-ID: <006201c75b4d$b47b7e30$800101df@vbs.local> When comminting out, it seems to work fine. [28/Feb/2007:18:31:42 +0100] conn=21 op=-1 fd=66 closed error 104 (Connection reset by peer) - TCP connection reset by peer. [28/Feb/2007:18:31:45 +0100] conn=114 fd=66 slot=66 connection from 192.168.100.118 to 192.168.100.120 [28/Feb/2007:18:31:45 +0100] conn=114 op=0 BIND dn="" method=128 version=3 [28/Feb/2007:18:31:45 +0100] conn=114 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [28/Feb/2007:18:31:45 +0100] conn=114 op=1 SRCH base="dc=van-boxtel-software,dc=nl" scope=2 filter="(&(objectClass=posixAccount)(uid=mvheukelom))" attrs="uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass" [28/Feb/2007:18:31:45 +0100] conn=114 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [28/Feb/2007:18:31:45 +0100] conn=114 op=2 SRCH base="dc=van-boxtel-software,dc=nl" scope=2 filter="(&(objectClass=posixAccount)(uid=mvheukelom))" attrs="uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass" [28/Feb/2007:18:31:45 +0100] conn=114 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [28/Feb/2007:18:31:54 +0100] conn=114 op=3 SRCH base="dc=van-boxtel-software,dc=nl" scope=2 filter="(&(objectClass=posixAccount)(uid=mvheukelom))" attrs="uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass" [28/Feb/2007:18:31:54 +0100] conn=114 op=3 RESULT err=0 tag=101 nentries=0 etime=0 [28/Feb/2007:18:31:54 +0100] conn=22 op=-1 fd=67 closed error 104 (Connection reset by peer) - TCP connection reset by peer. [28/Feb/2007:18:31:57 +0100] conn=115 fd=67 slot=67 connection from 192.168.100.118 to 192.168.100.120 [28/Feb/2007:18:31:57 +0100] conn=115 op=0 BIND dn="" method=128 version=3 [28/Feb/2007:18:31:57 +0100] conn=115 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [28/Feb/2007:18:31:57 +0100] conn=115 op=1 SRCH base="dc=van-boxtel-software,dc=nl" scope=2 filter="(uid=mvheukelom)" attrs=ALL [28/Feb/2007:18:31:57 +0100] conn=115 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [28/Feb/2007:18:31:59 +0100] conn=114 op=5 SRCH base="dc=van-boxtel-software,dc=nl" scope=2 filter="(&(objectClass=posixAccount)(uid=mvheukelom))" attrs="uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass" [28/Feb/2007:18:31:59 +0100] conn=114 op=5 RESULT err=0 tag=101 nentries=0 etime=0 err=0 so it looks o.k. thnx ----- Original Message ----- From: J. Hartman To: Fedora Directory server developer discussion. Sent: Wednesday, February 28, 2007 4:02 PM Subject: Re: [Fedora-directory-devel] LDAP Authentication Hi, In your client's ldap.conf, the rootbinddn should be set to a real account object, possibly the "cn=directory manager". In access log, you can see that the client is trying to bind as "dc=example,dc=com" (server's naming context!), and err=48 shows that the entry doesn't have userPassword attribute. Try commenting out the rootbinddn line or use "cn=directory manager". Regards, Joona Hartman On 2/28/07, Michiel van Heukelom - Van Boxtel Software BV < mvheukelom at van-boxtel-software.nl> wrote: Problem with authenticate. I've installed fedora-ds-1.0.4-1.RHEL4.i386.opt.rpm and it seems to be working fine. I can manage users by the console. On another machine i want to use the directory, but when ik log in, in /var/log/messages i get the following error: Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: check pass; user unknown Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: authentication failure; logname= uid=0 euid=0 tty=pts/2 ruser= rhost=192.168.100.176 Feb 23 13:07:59 ldap-vm4 remote(pam_unix)[3885]: could not identify user (from getpwnam(mvheukelom)) Feb 23 13:07:59 ldap-vm4 login[3885]: User not known to the underlying authentication module On my ldap server the file /opt/fedora-ds/slapd/logs/access [28/Feb/2007:11:27:49 +0100] conn=250 op=0 BIND dn="dc=example,dc=com" method=128 version=3 [28/Feb/2007:11:27:49 +0100] conn=250 op=0 RESULT err=48 tag=97 nentries=0 etime=0 [28/Feb/2007:11:27:51 +0100] conn=251 fd=67 slot=67 connection from 192.168.100.118 to 192.168.100.119 [28/Feb/2007:11:27:51 +0100] conn=251 op=0 BIND dn="dc=example,dc=com" method=128 version=3 [28/Feb/2007:11:27:51 +0100] conn=251 op=0 RESULT err=48 tag=97 nentries=0 etime=0 [28/Feb/2007:11:27:51 +0100] conn=251 op=1 UNBIND [28/Feb/2007:11:27:51 +0100] conn=251 op=1 fd=67 closed - U1 my ldap.conf on my client: host 192.168.100.119 base dc=Example,dc=com rootbinddn dc=example,dc=com In authconfig i've made the changes to: use ladap and user ldap authentication. I've also filled in my server (IP-number) and my base. Can someone advise me what to check please.... Best regards, Michiel van Heukelom Van Boxtel Software B.V. Phone: +31 (0) 492 - 327 357 Fax: +31 (0) 492 - 324 326 E-mail: mvheukelom at van-boxtel-software.nl Website: www.van-boxtel-software.nl -- 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 -------------- An HTML attachment was scrubbed... URL: