[389-users] Rolling upgrade of multiple servers

Rich Megginson rmeggins at redhat.com
Thu Jan 31 16:50:29 UTC 2013


On 01/31/2013 09:14 AM, Bright, Daniel wrote:
>
> When you say schema replication is tricky because it is a “single” 
> master, I am using an MMR environment where in effect every member is 
> a master. Is this a setting that is controlled elsewhere, and does 
> this mean that any custom changes to the schema need to be made on 
> this single master server?
>
>
> Yes.  That's the best way to do it.  If you make schema changes to one 
> master, then make sure that all of those schema changes have been 
> replicated to all servers throughout your topology, then you can make 
> schema changes to another master.  Schema replication is not 
> multi-master in the sense that you can make simultaneous changes to to 
> the schema on more than one master.  You just have to be careful.  
> That's why using a single master is easier - if you always make 
> changes on that one master, it should work.
>
> OK thanks, that is the way I am planning on doing this. Just for 
> clarification, the master schema server in an MMR environment is 
> whatever one I make changes to, it is however prudent to make schema 
> changes only to one server as normal replication rules do not apply to 
> schema and conflicts could arise if changes are made to more than one 
> master.
>

Right.

> *Custom Schema*
>
> If the standard 99user.ldiffile is used for custom schema, these 
> changes are replicated to all consumers.
>
> Custom schema files must be copied to each server in order to maintain 
> the information in the same schema file on all servers. Custom schema 
> files, and changes to those files, are not replicated, even if they 
> are made through the Directory Server Console or ldapmodify.
>
> If there are custom schema files, ensure that these files are copied 
> to all servers after making changes on the supplier. After all of the 
> files have been copied, restart the server.
>
> For more information on custom schema files, see Section 3.4.7, 
> “Creating Custom Schema Files” 
> <https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Directory_Schema.html#Customizing_the_Schema-Creating_Custom_Schema_Files>. 
>
>
>
> That's a little bit misleading.  In order for schema changes to be 
> replicated, they _must_ be changed using ldapmodify (which is what the 
> console uses).  Schema changes made over ldap are stored in 
> 99user.ldif.  However, if you manually edit 99user.ldif, schema 
> changes will _not_ be replicated.
>
> That is of course unless you restart the directory services on this 
> server, in the past when I’ve made changes to 99user.ldif they go into 
> effect when I restart the service, is this not true anymore? I haven’t 
> done this for a few years so perhaps I am remembering incorrectly.
>

When you make changes to 99user.ldif by editing the file, and then 
restart the server (or use the schema-reload.pl script), yes, the schema 
changes do go into effect immediately, but they are not replicated.

> CONFIDENTIALITY NOTICE
> This e-mail and any attachments contain information which may be 
> confidential or privileged and exempt from disclosure under applicable 
> law.  If you are not the intended recipient, be aware that any 
> disclosure, copying, distribution, or use of the contents of this 
> information is without authorization and is prohibited.  If you have 
> received this email in error, please immediately notify us by 
> returning it to the sender and delete this copy from your computer 
> system.  Thank you.
> ------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130131/aa38d739/attachment.html>


More information about the 389-users mailing list