I could try that sudoers and groups, but what about the attributes (like uidNumber and gidNumber) on the individual users that are in the replicated suffix?<br><br>-Lucas<br><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 12:07 PM, Rich Megginson <span dir="ltr">&lt;<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    On 08/30/2012 12:52 PM, Lucas Sweany wrote:
    <blockquote type="cite">I would like to protect certain entries in a hub
      389-ds host from getting obliterated during a full
      re-initialization of an agreement. Strange yes, but hear me out.<br>
      <br>
      To keep duty separation intact, we&#39;ve set up a scenario where
      we&#39;ve got one group managing Active Directory and one 389 server
      (389-A), and another group maintaining a 389 hub (389-B). 389-A
      syncs from AD one-way, and then replicates to 389-B.  However,
      things like sudoers and posix attributes (uids and gids) are
      managed on 389-B for convenience. Unfortunately, the sudoers OU
      and uids/gids get destroyed if 389-A performs a re-initialization
      of the agreement--by design I&#39;m sure.<br>
      <br>
      Is there a way to protect the sudoers OU and specific attributes
      of users on 389-B in this scenario? It looks like my options are
      to mess with fractional replication, ACIs, to meticulously back-up
      these attributes and restore them in the rare event we need to
      re-initialize, or to give up the convenience and have those
      attributes managed on 389-A. <br>
      <br>
      Is there no easy answer to this without giving up the ability to
      manage some things locally on 389-B?<br>
    </blockquote>
    <br></div></div>
    Can you separate the data by suffix?  The unit of replication is a
    database, so if you can create a sub-suffix in its own database, you
    could replicate that separately.<br>
    <br>
<a href="https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html" target="_blank">https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html</a><br>

    <blockquote type="cite"><br>
      Thanks,<br>
      <br>
      -Lucas<br>
      <br><span class="HOEnZb"><font color="#888888">
      <fieldset></fieldset>
      <br>
      <pre>--
389 users mailing list
<a href="mailto:389-users@lists.fedoraproject.org" target="_blank">389-users@lists.fedoraproject.org</a>
<a href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></pre>
    </font></span></blockquote>
    <br>
  </div>

</blockquote></div><br>