Well, LDAP is handled by the windows server ;) On Wed, Jun 2, 2010 at 8:53 PM, Joseph Sinclair wrote: > You don't really need the flat file or LDAP mirror. > The nslcd and nscd naming services cache daemons handle any caching you might need to handle momentary slowness or single packet drops, and it's a LOT simpler to manage. > Really, unless you're afraid of LDAP going *poof*, you won't have trouble with performance hitting LDAP directly. > > As for mail replication, the mail directories are just files; rsync can sync the mail directories just as well as any other files. > > Bryan O'Neal wrote: >> Google handles top posting so well :) >> A flat file would work as well. I suppose I just like the idea of >> local ldap querying remote ldap but flat file is more fool proof. And >> I had no intention of putting my mail server out in the DMZ - I was >> going to port forward either in a balanced fashion using multiple >> external ip's or in a a master slave relationship with a single >> external ip. I actually never put anything in the DMZ unless I can not >> find the rite port combination - example OS X using Vine - way to many >> undocumented ports involved their; after 4 hours I just put it in the >> dmz and called it a day. >> And yes I use software firewalls as well - mostly iptables >> >> On Wed, Jun 2, 2010 at 9:33 AM, Ed wrote: >>> Bryan - I think the idea is to separate the extraction of information >>> from the LDAP from the accessing of the information by Postfix. For >>> example drop the LDAP data to a flat file every X minutes - only if >>> there are changes - and have postfix access the flat file - aka on a >>> virtual_domain lookup use 'virtual_alias_domains = >>> hash:/etc/postfix/virtual_alias_maps' instead of virtual_alias_domains >>> = ldap: which can hang. I would do this for the config stuff and the >>> user lookup - once the email is in your system a momentary LDAP fail >>> is less of a problem - a delay not a drop. Also this means your LDAP >>> servers don't have to join your postfix gateways out in the DMZ - >>> which may be on the other end of an IPsec tunnel. etc etc >>> >>> we really shouldn't be top posting - Dennisk will kill me. �;) >>> >>> On Tue, Jun 1, 2010 at 11:11 PM, Bryan O'Neal >>> wrote: >>>> Good point for ldap - perhaps have a local ldap mirror in each server... >>>> >>>> On Tue, Jun 1, 2010 at 8:36 PM, Ed wrote: >>>>> Is this just a hot swap or some ghost servers? >>>>> >>>>> The best way is to set up your failover at the DNS level and at the >>>>> LDAP cluster. A heartbeat can bring on the mirror postfix if the >>>>> primary fails. You want to be dropping your LDAP info to a flat file >>>>> for postfix to work from on a regular interval - no reason for postfix >>>>> to stop if it can't reach the LDAP(s) "Temporary lookup failure". >>>>> Also, I would guess there is a database in there somewhere for the >>>>> email themselves - just make that a cluster too. >>>>> >>>>> I don't think Postfix is stateful on its own, just a queu that only >>>>> clears an email after delivery is confirmed to the next queu. If the >>>>> postfix machine dies before a message gets delivered, the message will >>>>> still be in the delivery queu, ready to be delivered. >>>>> or >>>>> http://readlist.com/lists/postfix.org/postfix-users/13/67961.html >>>>> or IPANY >>>>> http://www.gossamer-threads.com/lists/linuxha/users/63864 >>>>> >>>>> >>>>> On Sun, May 30, 2010 at 7:57 PM, Bryan O'Neal >>>>> wrote: >>>>>> Ok so I now have another postfix project (second one this week). This >>>>>> one specifies the following - CentOS servers, virtual users, ldap >>>>>> authentication (automatic user creation from ldap is a plus), and all >>>>>> mail and configs must be synced with a second box for redundancy. >>>>>> >>>>>> The configs are just an rsync issue, any recommendations on syncing mail? >>>>>> >>>>>> >>>>>> Any one want to give me there two cents or point to a favorite how too. >>>>>> --------------------------------------------------- >>>>>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >>>>>> To subscribe, unsubscribe, or to change your mail settings: >>>>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >>>>>> >>>>> --------------------------------------------------- >>>>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >>>>> To subscribe, unsubscribe, or to change your mail settings: >>>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >>>>> >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >>>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >>> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >> > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss