Re: Rolling upgrade of multiple servers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/31/2013 07:05 AM, Bright, Daniel wrote:

Hello,

 

I am performing a rolling upgrade of my 389-ds servers in my environment. Currently they are running version 1.2.5 of directory server, and 1.1.10 of administration server on 32-bit hardware. Currently I have 6 servers using MMR replication and I am planning on replacing the servers one at a time, upgrading from OEL5 32-bit to OEL6 64-bit and to version 1. 2.10.2 of directory server. Until the upgrades are completed, there will be a period of time where I have mixed servers, some 32-bit 1.2.5 and some 64-bit 1.2.10.2. I have done this in a test environment with 4 vm’s, and was able to detach a server from the MMR group, and then re-attach and initialize the new server successfully, with replication of the userRoot working seemingly fine. However, there are two issues I have noticed:

1 – any schema changes made on either the new servers or the old ones will not replicate over.


schema changes made over LDAP?  Yes, schema replication is tricky because it is "single" master.

2 – When I view the attributes tab on 389-console on the new 64-bit server, all attributes appear under “Standard Attributes”, however when I view the attributes tab on the 32-bit servers, about half of these are under the “User Defined Attributes” section. I have an idea of why this is but I want to hear someone else’s opinion on it first.


User defined attributes are attributes that have been added via LDAP (or the console which uses LDAP).

 

Also, if anyone has done this before and would like to share any issues they ran into I would be grateful. I’m wondering if the schema replication issue will go away once all servers are using 1.2.10.2.

 

Thanks in advance.

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.



--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux