[389-users] Protection of entries on downstream master or hub

[Lucas Sweany]

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?

-Lucas

On Thu, Aug 30, 2012 at 12:07 PM, Rich Megginson <rmeggins at redhat.com>wrote:

>  On 08/30/2012 12:52 PM, Lucas Sweany wrote:
>
> 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.
>
> To keep duty separation intact, we've set up a scenario where we'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'm sure.
>
> 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.
>
> Is there no easy answer to this without giving up the ability to manage
> some things locally on 389-B?
>
>
> 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.
>
>
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html
>
>
> Thanks,
>
> -Lucas
>
>
> --
> 389 users mailing list389-users at lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120830/392de4b7/attachment.html>