<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Feb 23, 2016, at 4:22 AM, Ludwig Krispenz <<a href="mailto:lkrispen@redhat.com" class="">lkrispen@redhat.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><br class="">
On 02/22/2016 11:51 PM, Timothy Geier wrote:<br class="">
<blockquote type="cite" class=""><br class="">
What’s the established procedure to start a 389 instance without any replication agreements enabled? The only thing that seemed close on google (<a href="http://directory.fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html" class="">http://directory.fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html</a>)
seems risky and couldn’t be done<br class="">
trivially in a production environment.<br class="">
</blockquote>
no, this is about how to get out of problems when replication could no longer synchronize its csn time generation, either by too many accumulate time drifts o playing with system time, hope you don't have to go thru this.<br class="">
<br class="">
Enabling disabling a replication agreement can be done by setting the configuration parameter:<br class="">
<br class="">
look for replication agreements (entries with objectclass=nsDS5ReplicationAgreement) and set<br class="">
nsds5ReplicaEnabled: off<br class="">
<br class="">
you can do this with an ldapmodify when the server is running or by editing /etc/dirsrv/slapd-<INSTANCE>/dse.ldif when teh server is stopped<br class="">
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">Thanks for the procedure..the good news is this worked quite well in making sure that 389 didn’t crash immediately after startup. The bad news is that the certificates still didn’t renew due to </div>
<div class=""><br class="">
</div>
<div class=""><span style="font-size: 10pt;" class="">Server at "</span><a href="https://mail.accertify.com/owa/redir.aspx?REF=hBo37W2qnlmUfAeXTrhGw6WdavZzsQoMPQ85UuuxxhZLgX6LCUDTCAFodHRwOi8vbWFzdGVyX3NlcnZlcjo4MDgwL2NhL2VlL2NhL3Byb2ZpbGVTdWJtaXQ." target="_blank" style="font-size: 10pt;" class="">http://master_server:8080/ca/ee/ca/profileSubmit</a><span style="font-size: 10pt;" class="">"
replied: </span><span style="font-size: 10pt;" class="">Profile caServerCert Not Found</span></div>
<div class=""><br class="">
</div>
<div class="">which was the same error in getcert list I saw that one time 389 didn’t crash right away. At least now this can be further troubleshooted without worrying about 389.</div>
<br class="">
<br class="">
</body>
</html>
<pre>
"This message and any attachments may contain confidential information. If you
have received this message in error, any use or distribution is prohibited.
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."</pre>