389-devel February 2007

389-devel@lists.fedoraproject.org

13 participants
35 discussions

[Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core"
by Rich Megginson 19 Feb '07

19 Feb '07

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.

5 6

[Fedora-directory-devel] Please review: Bug 229286: Solaris build: link shared libs correctly with libtool
by Rich Megginson 19 Feb '07

19 Feb '07

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

1 0

[Fedora-directory-devel] Please Review: (229095) HP-UX build not using pthread properly
by Nathan Kinder 16 Feb '07

16 Feb '07

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

1 0

[Fedora-directory-devel] Please review: Bug 228334: Allow building with bdb 4.4 or later
by Rich Megginson 12 Feb '07

12 Feb '07

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

1 0

[Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location
by Rich Megginson 12 Feb '07

12 Feb '07

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

2 1

[Fedora-directory-devel] Unique mail-id
by linx-tech user 10 Feb '07

10 Feb '07

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 --------------------------------- Heres a new way to find what you're looking for - Yahoo! Answers

1 0

[Fedora-directory-devel] Re: Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location
by Howard Chu 09 Feb '07

09 Feb '07

> Date: Fri, 09 Feb 2007 10:37:19 -0700 > From: Richard Megginson <rmeggins(a)redhat.com> >>> >> Date: Fri, 09 Feb 2007 08:15:11 -0700 >>> > > From: Richard Megginson <rmeggins(a)redhat.com> >>> >> 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/

1 0

Re: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location
by Howard Chu 09 Feb '07

09 Feb '07

> Date: Fri, 09 Feb 2007 08:15:11 -0700 > From: Richard Megginson <rmeggins(a)redhat.com> > 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/

5 6

[Fedora-directory-devel] Please Review: (228082) Wrappers need to support legacy bundled builds
by Nathan Kinder 09 Feb '07

09 Feb '07

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

1 0

[Fedora-directory-devel] Please review: Bug 160235: Add support for /etc/init scripts
by Rich Megginson 09 Feb '07

09 Feb '07

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel February 2007