Failover between masters

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

 



I've never seen it work adequately with RHEL 3 & 4  or Solaris 8 clients
(solaris 9 seems to work fine).  We use Piranha (which also distributes
the load nicely) to get around it.

-Steve

On Thu, 2007-03-29 at 08:20 +0800, Coe, Colin C. (Unix Engineer) wrote:
> 
> Hi all
> 
> We are currently using Sun's Directory server and have had some
> problems with clients failing over to the other master if one fails.
> The clients are a minxute of RHEL 3 WS and Solaris 8 (SPARC), and the
> Sun Directory servers are both Solars 9 (SPARC) running Directory One
> 5.1.
> 
> /etc/ldap.conf 
> host 1.1.1.1 2.2.2.2 
> port 636 
> ldap_version 3 
> base o=unix,dc=company,dc=com 
> scope sub 
> timelimit 5 
> bind_timelimit 3 
> ssl on 
> pam_filter objectclass=posixAccount 
> pam_login_attribute uid 
> pam_member_attribute memberUid 
> pam_password crypt 
> idle_timelimit 3600
> 
> /etc/openldap/ldap.conf 
> BASE o=unix,dc=company,dc=com 
> HOST ldap1.company.com ldap2.company.com 
> PORT 636 
> SASL_SECPROPS "noanonymous,noplain" 
> SIZELIMIT 0 
> TIMELIMIT 0 
> DEREF never 
> TLS_CACERT      /etc/ssl/ldap/cacert.pem 
> TLS_REQCERT     demand
> 
> We're using the bog standard nscd daemons provided by the OS vendors.
> We also use IDSync to synchronise user passwords from AD to LDAP but
> not from LDAP to AD.
> 
> What we're finding is if ldap1 dies for some reason, the clients don't
> failover to ldap2.  
> 
> We don't know if the problem is client side or server side.  Would
> Fedora Directory Server, set up in a similar manner, also not failover
> properly?  While we're prepared to look at Fed DS, there is a feeling
> that it too will behave in the same manner, given they are both forks
> of the same project.
> 
> Comments?
> 
> Thanks
> 
> CC
> 
> NOTICE: This email and any attachments are confidential. 
> They may contain legally privileged information or 
> copyright material. You must not read, copy, use or 
> disclose them without authorisation. If you are not an 
> intended recipient, please contact us at once by return 
> email and then delete both messages and all attachments.
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-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