Dear Jeff I really understand your point of view, and I agree with that but I disagree in one point: we should expect that something can occurs, being an attack, a server down, etc, etc, although we have to give QoS to the client because he is paying for being served! Like the restaurants we like to be well served because we are paying for it! you Know!
The problem here is not the server being down, but when he comes up. in that time being 1 minute or 1 hour or 1 year, many clients can update their profiles and that information must be consistent in every databases, mainly in the master server. If the problem can be resolved by an application why should we solve it mannualy! Well we have to think that things going to happen, they don't happen only to our neighbour! thanks for your advice, and I let you know if I implement something! Hugo Tavares ************************************************* You should ask yourself this question: You don't expect your master LDAP server to fail frequently, if you do then you better examine other parts of you deployment. On the rare occasions that the LDAP server fails, the outages will usually be short in duration. Do you really need to allow write access to the Directory for these times the master is down? For most LDAP deployments I would think that it's not worth the investment in working out this reverse replication thing. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
