I have set up a nightly development yum repository for 389 Directory
Server builds from "master". There are currently builds available for
Fedora 18 (x86_64 and i686). I will work on adding builds for rawhide
(F19) in the near future. New builds are made nightly from the "master"
branch in Git, which will be updated to the repo around 12:00 UTC-08:00.
To set a system up to use the development repository, download the
following repo file and place it in the /etc/yum.repos.d directory:
It is very important to understand what the purpose of this repo is (and
what it is NOT). These are test builds that are provided for
convenience for use in development and testing. The builds will very
likely be unstable at times. You should NOT try to run these builds for
anything important. I expect these builds to be used by the 389
development team for testing as we approach the release of new official
packages. I also expect that these builds will be useful for other open
source projects (such as FreeIPA) who want early access to upcoming 389
Directory Server versions during their own development cycles. It is
also perfectly fine to use these builds to preview upcoming features and
play with them, as long don't expect everything to always be stable and
If you do encounter issues with the development builds that seem like
bugs, please let us know about them. You can bring them up on our IRC
channel (#389 on FreeNode), or file a ticket for it in our Trac instance
Please let me know if you encounter any problems with the repository.
Bug description: DNA config updates were always put into the
event queue and executed in 30 seconds, which increased a chance
to conflict with the ordinary modify operations and cause db
Fix description: The 30 seconds delay is necessary at the start-
up time when MMR is configured to guarantee the shared config is
logged in the changelog. This patch leaves the behaviour of the
config update at the start-up as it is; the rest won't be queued
but updated immediately.
There has been a request to remove instance specific scripts, and make
them generic and placed in /usr/sbin/
Should we remove all the scripts from /usr/lib64/dirsrv/slapd-INSTANCE:
bak2db db2index dn2rdn ldif2ldap
ns-newpwpolicy.pl start-slapd usn-tombstone-cleanup.pl
bak2db.pl db2index.pl fixup-linkedattrs.pl monitor
restart-slapd stop-slapd verify-db.pl
cleanallruv.pl db2ldif fixup-memberof.pl ns-accountstatus.pl
restoreconfig suffix2instance vlvindex
db2bak db2ldif.pl ldif2db ns-activate.pl
db2bak.pl dbverify ldif2db.pl ns-inactivate.pl
It appears almost of these are all instance specific. Do we want to
make all of these "generic" and stick them in /usr/sbin?
However, I think it makes sense to keep some instance specific scripts:
monitor, stop/start/restart, maybe the "task" scripts too (like schema
reload, cleanallruv, fix-memberof, etc). Then only make the database
scripts generic: db2ldif db2index, ldif2db, db2bak, bak2db, etc.
Just curious what everyone thinks about this.
Red Hat, Inc
Bug description: In the server side sorting compare function
compare_entries_sv, if multiple attribute types are specified,
the sort spec for each attribute is scanned one by one in the
for loop. In the for loop, instead of using the "current"
spec, the first spec is kept using. If the attribute types
have different syntaxes (e.g., cis, tel), then the first
syntax is unexpectedly selected for the second syntax.
Fix description: This patch correctly uses the current spec
in the for loop.