[Fedora-directory-devel] HowTo:ChainOnUpdate
by Nate Huddleson
I have attempted to follow the instructions included in the
HowTo:ChainOnUpdate, but have run into a problem when attempting to
configure the chaining backend for the chaining plugin. After digging for a
while, I discovered that my problem seemed to be that the attributes used
(such as "nsFarmServerURL" and "nsMultiplexorBindDN", etc, etc) are not
defined in the schema. I have checked out the source code for FDS 1.0,
1.0.1, 1.0.2, 1.0.3 and 1.0.4 and have not been able to find the schema file
that contains these attributes. Can anybody help me with finding the schema
file and/or the correct way to set up Chaining on Update?
Thanks,
Nate.
P.S. I am trying to set up a master-slave system with a Round Robin DNS in
front of it for load balancing. I wanted to set up the chain on update so
that all the clients can see the system as a single server, rather than a
collection of servers.
16 years, 9 months
[Fedora-directory-devel] Please review: Bug 248145: Replace ds_newinst binary with perl script
by Rich Megginson
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248145
Resolves: bug 248145
Bug Description: Replace ds_newinst binary with perl script
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The time has come. We can finally get rid of the
instance creation C code
once and for all. I've created a DSCreate module that has all of the
functionality of the old
create_instance.c code, along with a few items from ldap/admin/lib.
The way it works is
this: it first creates the dse.ldif file using template-dse.ldif and
the suffix-db template to
create the initial db and suffix. It then adds additional optional
configuration depending
on what optional features have been enabled. It creates other config
files and copies in
the schema. It then initializes the database. It uses a template file
based on the type of
entry implied by the suffix, then adds the default ACIs. If the user
chose to do so, it
will also create the ou=people, ou=groups, etc. entries. The user can
also supply an LDIF
file which will be used to populate the initial database, in which case
none of the default
entries or ACIs will be used. It then starts the server (if desired).
I had to create a function makePaths that works like mkdir -p except
that it will chown,
chgrp, and chmod all paths created.
I had to change the other places where instance creation was called to
use the new
calling semantics. ds_create changed quite a bit, since it can just
use an Inf to pass in the
information instead of calling ds_newinst as a CGI program.
I had to change FileConn to add support for namingContexts (i.e.
entries with no parent),
and to have it write each change each time, and to return copies of
entries when searching,
to avoid modifying the tree in place. This makes it act much more like
LDAP.
I found and fixed a few bugs in Migration along the way that were
revealed while integrating
the new DSCreate code.
Platforms tested: RHEL4, FC6
Flag Day: Yes. New instance creation code and autotool changes.
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=159175
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=159187&action=diff
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=159188&action=diff
16 years, 9 months
[Fedora-directory-devel] Please review: Bug 245815: DS Admin Migration framework - cross platform support
by Rich Megginson
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245815
Resolves: bug 245815
Bug Description: DS Admin Migration framework - cross platform support
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: There are basically three parts to cross platform support
1) Allow a different physical server root than the logical server root.
This allows you to copy the old server root directory to the target
machine, either by making a tarball or by a network mount. Then you can
migrate from e.g. /mnt/opt/fedora-ds, and specify that the real old
server root was /opt/fedora-ds. This is the distinction between the
--oldsroot and --actualsroot parameters.
2) Cross platform database migration requires the old data is converted
to LDIF first. Migration makes the simplifying assumption that the
database LDIF file is in the old db directory and has the name of <old
backend name>.ldif e.g. userRoot.ldif
3) Cross platform replication migration doesn't preserve the state, so
the changelog nor other associated state information can be migrated.
I rewrote the old migration script to use the FileConn - this
theoretically will allow us to support migration using an LDAP::Conn as
well.
I had to make some fixes to FileConn, primarily to support the root DSE.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158883&action=diff
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158885&action=diff
16 years, 9 months
[Fedora-directory-devel] Please review: [Bug 247215] Reimplement ds_remove without setuputil code
by Noriko Hosoi
Summary: Reimplement ds_remove without setuputil code
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247215
With these changes, we really don't need to "install" setuputil, any more!
Thanks,
--noriko
------- Additional Comments From nhosoi(a)redhat.com 2007-07-10 14:29 EST -------
Created an attachment (id=158876)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158876&action=view)
cvs diff (ldapserver)
Files:
admin/src/create_instance.c
servers/slapd/libglobs.c
servers/slapd/slap.h
Description: adding nsslapd-instancedir to dse.ldif. Note that no setter nor
getter function is implemented. The instance dir info is added to dse.ldif
when the server instance is generated and never meant to be touched. It's
needed for ds_remove to find out the instance directory.
------- Additional Comments From nhosoi(a)redhat.com 2007-07-10 14:35 EST -------
Created an attachment (id=158879)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158879&action=view)
cvs diff (adminserver)
Modified Files:
Makefile.am
admserv/newinst/src/AdminUtil.pm.in
admserv/newinst/src/adminserver.map.in
admserv/newinst/src/configdsroot.map.in
admserv/newinst/src/dirserver.map.in
admserv/newinst/src/register_param.map.in
admserv/schema/ldif/10rm_dsdata.ldif.tmpl
New Files:
admserv/cgi-src40/ds_remove.in
admserv/cgi-src40/ds_remove.res
Description: adding Perl version of ds_remove
The script runs as CGI receiving the input "InstanceName" from, e.g., Console.
It gathers the server info using the Resource module and config files -- both
Admin and Directory Servers'.
Then, stops the server, clean up the instance's info from the Configuration
Directory Server, and remove the physical directories and files.
16 years, 9 months