eDirectory Synchronization only between 23:00 and 0:00 o'clock or manually

I've got an eDirectory v8.8.2 and an iManager v2.7 on two Linux SLES9 Servers.
This eDirectory has nearly 250.000 PKI-Objects in one tree.
Now I like to configure, that the Master Server replicates its Data every Night only between eleven and twelve o'clock or better manually via script to the Replica Server.
Has anybody a solution for me, how I can configure it?

Thanks for your help
Who is Participating?
You can disable sync and enable it: Create a script to use these dstrace commands:

set dstrace=!D <hours>
Disables inbound and outband synchronization for the specified number of hours, default is 24.

set dstrace=!E
Enables inbound and outbound synchronization.

Then you could use
set dstrace=+S
set dstrace=*H

to kick off a sync after your set dstrace=!E

Other handy dstrace commands:
set dstrace=!DI <hours> disables inbound sync only, default is 24 hours
set dstrace=!DO <hours> disables outbound sync only, default is 24 hours
set dstrace=!EI enables inbound sync only
set dstrace=!EO enables outbound sync only

Just because you CAN do a thing doesn't mean you SHOULD do a thing. :-) But, given your situation, if you make sure that your servers are getting their time from a reliable ntp source you should be fine.
Why?  Are you seeing a lot of sync traffic?

The purpose of replicating as-needed is so a read-write replica can accept changes and sync back to the master, and vice-versa, interchangeably throughout the day, minimizing the possibility of conflicting changes.

eDirectory does not do a full sync of all objects unless you tell it to.  It only sends deltas between the replicas in the replica ring.  It doesn't much matter how many objects there are - it matters how many changes to objects there are.

Please keep in mind that, unlike Active Directory, eDirectory does not populate inherited ACL's through all objects subject to inheritance - if you make a rights/permissions change to a parent object, the only change is to the parent object.  The child objects dynamically inherit the rights.  This is true for both eDirectory rights and filesystem rights.

If you have a WAN with extremely limited bandwidth, there are methods for reducing the sync traffic, but on a LAN - unless you have a ton of changes all day long - you won't see much more than "got anything?" - "Nope" every so often...  

Bottom line, doing what you're thinking of doing is more likely to cause problems than to solve them.
Further, 250K objects is no big deal for eDirectory.  It's designed to handle over a billion objects - and has been proven to be capable of that, in much earlier versions than what you have.  It's also designed for efficiency.

Another thing to consider - if you stop sync and do it only once a day, and change permissions/rights on a parent object, the parent object will only have the changed permissions/rights on the replica to which the change was made.  That opens the door for major inconsistencies for the rest of the day, depending on which replica the child object references.
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!


For the manual sync, you may use crontab to schedule the script that will do the sync between the two servers.

- The synchronization script should be executable (use chmod u+x myscript)
- In the synchronization script define / set all necessary env variables
- In the synchronization script use full path names of commands and files
- To run the crontab job, create a crontab file:

crontab -l >> mycrontab

The above command will capture the current crontab jobs

- edit (e.g. using vi)  mycrontab file and add the following line to it:

0  23  *  *  * /path/to/script/myscript >> /path/to/my/logs/myscript.log 2>&1

The above will run the required script at 11:00 PM everyday. The script will run till it finishes (or if you have controls within the script itself to finish / terminate in one hour).

stdout and stdout are redirected to /path/to/my/logs/myscript.log

- submit the crontab file

crontab mycrontab

crontab -l

for more info on crontab, please see:

That would be groovy for, for example, an Rsync script.   eDirectory replica synchronization happens when it happens.

There is a setting - don't know where it's set on Linux eDir 8.8x, but it is "inactivity sync interval" which determines how frequently a sync occurs when the network is relatively idle.  Password changes sync immediate but other, less-critical changes can be delayed to minimize sync traffic.

I don't think that interval can be set to 24 hours though.
I'd have to ask the same question - Why?

Unless your eDirectory objects are constantly being modified in large numbers, the sync traffic should be minimal.
chief-MHAuthor Commented:
Hi everybody,
thank you for your comments.

about your question why:
This eDirectory is not for Usermanagment and Logins.
We choose eDir for storing global PKI signatures (500.000 objects and more), because of the performance.
Everyday we get LDIFs, from a Trustcenter, which were imported to the Master eDir. The R/W Replica should have the old stand because the PKI signatures, which were old, might be interested the day after, when the OPC job didn't work.
So all jobs (import LDIFS, the eDir sync and the Data verifying) were processed by the Mainframe with its OPC jobs.

So there are no problems with sync performance, major inconsistencies, or automatic jobs.
@omarfarid: The script for that crontab will be interessted

Thanks for your help
Sir might be interested in a copy of this (if he doesn't have it):

For people who really use the power of eDirectory it's an outstanding tool. Might be a cleaner option than interrupting the sync process.

Regardless of what you use eDirectory for, you need to understand how it is structured, physically, and why.   eDirectory is a multimaster database, not a bunch of standalone databases that syncs now and then.

Its replication is not for backup purposes.  It is partly for fault-tolerance and partly for load-balancing and availability.  A read-write replica of a Master partiton replica is a fully-participating replica, not a backup copy.  

If you want to have a backup copy snapshot-in-time of the directory, you need to make a backup copy of the directory.  
chief-MHAuthor Commented:
Hello ShineOn,

I need a LDAP based Directory with high performance. Shure I can use OpenLDAP Server, but in our Tests it was nearly 50% slower and with so many objects, it is a lot of time.
At the moment we use Active Diretory and eDirectory (for GroupWise) and we didn't like a third Directory in our Network.

So is there a possible solution with eDir?
eDirectory is known to be a top performer for LDAP, and is also one of a handful of directory services that are LDAPv3 certified by the Open Group.  However, I don't think what you're trying to do with eDirectory is something that any other directory service also wouldn't be designed to do.

When you have a read/write replica of an eDirectory partition, it's not a backup copy, it is a fully-participating second master in the multimaster database.  If you want a backup copy, don't do it with a replica.

Perhaps you could have two different trees, and somehow rotate them?

eDirectory, if you interrupt communication between replicas, will complain that it can't contact its replica, and may eventually begin to issue warnings about synthetic time, because it can't tell whether or not the other server is in sync.  It's not designed to sync on-demand.  Yes, you can issue a ds repair utility command that would force a sync, but there's nothing I'm aware of to turn off sync and only sync on-demand.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.