I am fairly new to LDAP administration and was wondering approximately how
long it should take to import approximately 500,000 user records.
I have tried from both the administration console as well as the from the
command line and everything seems to be taking forever (days). I don't have
a lot to compare it to, but I have a feeling that even with this many
records into a single LDAP instance should go a lot faster.
We've just had a huge scare. We reboot our main LDAP server (CentOS DS
8.1 on newly upgraded CentOS 5.4) and it dirsrv failed to start.
dse.ldif was completely empty. Thankfully, I had a near-line backup. I
restored it and restarted and we seem to be OK. What would cause such a
problem? Thanks - John
John A. Sullivan III
Open Source Development Corporation
Making Christianity intelligible to secular society
I'm following the guide in this URL:
Seeing the item 3, this says the following:
"Back on the left, expand the Replication Folder until you see your
databases. Click on the database you wish to replicate. On the right you
will see a menu in which you need to use the following options."
I see 2 options in the console: NetscapeRoot and userRoot.
I configured MMR for NetscapeRoot, due I thought it is the root of the
directory, then I need to setup that database, but as I'm not
replicating an entry, I'm thinking I should need to select the second
one for users.
If that is the case, I can configure MMR for the userRoot database, but
what do I do with the another one? do I delete it, or that is necessary
to replicate the changes on the schema and everything is in the root of
Centro de Difusión del Software Libre.
Previous setup: Fedora directory server 1.2.0. ssl, replication all
Current setup: 389 dir server, $latest.
I cannot state enough how pleased I am with the upgrade. The
instructions on the web page were flawless, the update was frankly,
probably the simplest thing I've done this week on a software package
system that's the most complex and critical of what I currently manage.
I half expected SOME hiccups, errors, or things out of sync, or broken
replication, or SOMETHING... and so on. Instead-- it just went
Awesome. Absolutely awesome.
Keep up the good work.
--Kent C. Brodie, Medical College of Wisconsin
We're using FDS (389) 1.2.0.
A few days ago, this started showing up in the logs on one of our two
[17/Oct/2009:10:46:13 -0500] NSMMReplicationPlugin -
agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer
failed to replay change (uniqueid 8d7abe0d-812811de-837b9eef-94681f9f,
CSN 4a7b3c31000000020000): DSA is unwilling to perform. Will retry
... every 5 minutes. It's all the same "uniqueid", so it appears to
be one particular replication request that just didn't work (don't know
Replication is otherwise "OK"....
What can I do to :
* find out what replication change is failing,
* why--- and
* what can I do about it?
I'm a bit new to this, so any help is greatly appreciated!
(Presumably, I need a way to either accept the change, or probably also
just indicate that the change, whatever it was, doesn't need to occur).
I am supporting an outfit that has two FDS servers configured for
multiple-master replication. I do not have access to these servers.
Today it was observed that on both of these servers, a user logging into
the FDS Console as cn=Directory Manager is unable to edit the advanced
properties on a user (to unlock a user's account), and that the Users OU
is marked with a red X.
I can not find any documentation that discusses why this red X would
appear. What does this mean?
Users of the systems supported by these FDS servers are still able to
authenticate against the servers, and the administrators of the servers
can not find anything relevant in the error logs. Is there anything you
could suggest looking for?
Secure Systems Engineer
Trusted Computer Solutions
2350 Corporate Park Drive, Suite 500
Herndon, Virginia 20170
Tel (703) 537-4382 | Fax (703) 318-5041