[Fedora-directory-devel] Proposal: name the new core package "fedora-ds-core"
by Rich Megginson
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.
17 years, 2 months
[Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location
by Rich Megginson
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
17 years, 2 months
[Fedora-directory-devel] Unique mail-id
by linx-tech user
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
17 years, 2 months
[Fedora-directory-devel] Re: Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location
by Howard Chu
> 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/
17 years, 2 months
Re: [Fedora-directory-devel] Please review: Bug 227771: FHS: use sysconfdir (/etc) as config file location
by Howard Chu
> 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/
17 years, 2 months
[Fedora-directory-devel] Please review: Bug 160235: Add support for /etc/init scripts
by Rich Megginson
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
17 years, 2 months