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 ?
-jf
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@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
On 2009-02-17, Rich Megginson <rmeggins@redhat.com> wrote:> > 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.Ok, as I expected, thanks for clarifying! -jf
Hello, We had some bad experiences manipulating 99users.ldif in the past. I confirm that Rich''s method is the good one. To do so, we setted up several schemas : # ls /etc/dirsrv/<slapd-instance>/schema 00core.ldif 20subscriber.ldif 50ns-directory.ldif *91supann.ldif* 01common.ldif 25java-object.ldif 50ns-mail.ldif *92inrp.ldif* 05rfc2247.ldif 28pilot.ldif 50ns-value.ldif *93radius.ldif* 05rfc2927.ldif 30ns-common.ldif 50ns-web.ldif *94fw1.ldif* 10presence.ldif 50ns-admin.ldif 60pam-plugin.ldif 99user.ldif 10rfc2307.ldif 50ns-certificate.ldif *90eduperson.ldif* We used 9x prefixes to avoid collisions with futur schemas : *90eduperson.ldif : is for Internet 2* *91supann.ldif : is for French Academic adaptations to Internet 2 **92inrp.ldif : is for local attributes (instead of 99user !) **93radius.ldif : is for radius serveur (eduroam services) **94fw1.ldif : is for CheckPoint Firewall 1 RemoteSecure (VPN) users These schemas are installed before FDS first start. ** *These are classes setted up for employees : dn: uid=<my user>,ou=people,dc=inrp,dc=fr objectClass: supannPerson objectClass: eduPerson objectClass: posixAccount objectClass: shadowAccount objectClass: inetorgPerson objectClass: inrpPerson objectClass: inrpLan objectClass: inrpWifi objectClass: fw1person objectClass: mailRecipient objectClass: ntUser The people branch drives : postfix, Active Directory, unix ftp, radius, Intranet applications...(not exhaustive) Successful tests with MacOS X and pGina (Windows LDAP/Gina pam module without a domain controler) Regards, Jan-Frode Myklebust a écrit :> 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 ? >-- *Nicolas CAREL **Service Commun Informatique *Chef de service Tel : 04 72 76 61 43 - e-mail : nicolas.carel@inrp.fr *Institut National de Recherche Pédagogique <http://www.inrp.fr/>*19 allée de Fontenay - B.P. 17424 - 69347 LYON CEDEX 07 Standard : 04 72 76 61 00 - Télécopie : 04 72 76 61 10