[Fedora-directory-users] schema replication

Rich Megginson rmeggins at redhat.com
Tue Feb 17 21:14:10 UTC 2009


Jan-Frode Myklebust wrote:
> We just had a bit of a scary situation.. We have two multimaster
> replicating directory servers (server1 and server2), with a few
> schema modifications residing in 99user.ldif.
>
> dc=example, dc=com:
>
>   server1 <---> server2
>
> Then we wanted to make these two directory servers be consumers
> of another directory on server3, which has another set of schema
> modifications in 99user.ldif. The result was that server1 and server2
> dropped all their modifications to 99user.ldif, and started using a 
> 99.ldif identical to server3. Resulting in lots of problems with 
> unknown object classes in their original directory tree..
>
> o=ISP, o=example, c=NO
>
>               server3 (single master)
>               /      \
>           server1   server2 (consumers)
>
> Which makes me wonder what the correct way of handling local
> schema modifications are. Should we be creating our own 99my_classes.ldif,
> instead of storing them in 99user.ldif ?
>   
The best way is to create your own schema files (e.g. 70myschema.ldif), 
copy them to the /etc/dirsrv/slapd-instance/schema directory, and use 
the schema reload task 
(/usr/lib[64]/dirsrv/slapd-instance/schema-reload.pl) to reload the schema.
99user.ldif is mostly useful for ad-hoc schema, when you are trying to 
design your schema and making changes to it frequently.  Once your 
schema is stable, store it in a separate file.  Also, as you have found 
out, schema replication is single master only.
>
>    -jf
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090217/d6752722/attachment.bin>


More information about the 389-users mailing list