Well, LDAP is handled by the windows server ;)
On Wed, Jun 2, 2010 at 8:53 PM, Joseph Sinclair
<
plug-discussion@stcaz.net> 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 <plug@0x1b.com> 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
>>> <Bryan.ONeal@theonealandassociates.com> wrote:
>>>> Good point for ldap - perhaps have a local ldap mirror in each server...
>>>>
>>>> On Tue, Jun 1, 2010 at 8:36 PM, Ed <plug@0x1b.com> 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
>>>>> <Bryan.ONeal@theonealandassociates.com> 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
(text/plain)